https://wiki.archlinux.org/api.php?action=feedcontributions&user=Bwid&feedformat=atomArchWiki - User contributions [en]2024-03-29T12:16:42ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=373864Beginners' guide2015-05-16T04:47:13Z<p>Bwid: /* Hostname */ This isn't necessary. It's sufficient when the loopback address gets the name localhost. The linked section in "Network configuration" also does not mention a need for this.</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:Beginners' Guide]]<br />
[[bg:Beginners' Guide]]<br />
[[cs:Beginners' Guide]]<br />
[[da:Beginners' Guide]]<br />
[[de:Anleitung für Einsteiger]]<br />
[[el:Beginners' Guide]]<br />
[[es:Beginners' Guide]]<br />
[[fa:راهنمای تازهکارها]]<br />
[[fr:Installation]]<br />
[[he:Beginners' Guide]]<br />
[[hr:Beginners' Guide]]<br />
[[hu:Beginners' Guide]]<br />
[[id:Beginners' Guide]]<br />
[[it:Beginners' Guide]]<br />
[[ja:ビギナーズガイド]]<br />
[[ko:Beginners' Guide]]<br />
[[lt:Beginners' Guide]]<br />
[[nl:Beginners' Guide]]<br />
[[pl:Beginners' Guide]]<br />
[[pt:Beginners' Guide]]<br />
[[ro:Ghidul începătorilor]]<br />
[[ru:Beginners' guide]]<br />
[[sk:Beginners' Guide]]<br />
[[sr:Beginners' Guide]]<br />
[[sv:Nybörjarguiden]]<br />
[[tr:Yeni başlayanlar rehberi]]<br />
[[uk:Beginners' Guide]]<br />
[[zh-CN:Beginners' guide]]<br />
[[zh-TW:Beginners' Guide]]<br />
{{Related articles start}}<br />
{{Related|:Category:Accessibility}}<br />
{{Related|Installation guide}}<br />
{{Related|Diskless system}}<br />
{{Related|Install from SSH}}<br />
{{Related|General recommendations}}<br />
{{Related|General troubleshooting}}<br />
{{Related articles end}}<br />
This document will guide you through the process of installing [[Arch Linux]] using the [https://projects.archlinux.org/arch-install-scripts.git/ Arch Install Scripts]. Before installing, you are advised to skim over the [[FAQ]].<br />
<br />
The community-maintained [[Main page|ArchWiki]] is the primary resource that should be consulted if issues arise. The [[IRC channel]] (irc://irc.freenode.net/#archlinux) and the [https://bbs.archlinux.org/ forums] are also excellent resources if an answer cannot be found elsewhere. In accordance with [[the Arch Way]], you are encouraged to type {{ic|man ''command''}} to read the [[man page]] of any command you are unfamiliar with.<br />
<br />
== Minimum system requirements ==<br />
<br />
Arch Linux should run on any [[Wikipedia:P6 (microarchitecture)|i686]] compatible machine with a minimum of 256 MB RAM. A basic installation with all packages from the {{Grp|base}} group should take less than 800 MB of disk space. If you are working with limited space, this can be trimmed down considerably, but you will have to know what you are doing.<br />
<br />
== Prepare the latest installation medium ==<br />
<br />
{{Tip|Compared to the regular ISO images, the [https://downloads.archlinux.de/iso/archboot/latest archboot] images can take several steps explained in this guide [[Archboot#Interactive_setup_features|interactively]]. See [[Archboot]] for details.}}<br />
<br />
The installation media and their [[GnuPG]] signatures can be acquired from the [https://archlinux.org/download/ Download] page. The single ISO image supports both 32bit and 64bit systems; this guide assumes you use the latest available version.<br />
<br />
It is highly recommended to verify the image signature before use, ''especially when downloading from an HTTP mirror'', as these are run by volunteers who could [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#explanation theoretically serve malicious images]. On a system with GnuPG installed, do this by downloading the ''PGP signature'' (under ''Checksums'') to the ISO directory, and run:<br />
<br />
$ gpg --verify archlinux-''version''-dual.iso.sig<br />
<br />
If the public key is not found, [[GnuPG#Import key|import]] it with {{ic|gpg --recv-keys ''key-id''}}. <br />
<br />
Alternatively, run from an existing Arch Linux installation:<br />
<br />
$ pacman-key -v archlinux-''version''-dual.iso.sig<br />
<br />
Now choose one of the methods from the table below to [[#Boot the installation medium]] on the target machine(s). As the installation process retrieves packages from a remote repository, these methods require an internet connection; see [[Offline installation of packages]] when none is available.<br />
<br />
{| class="wikitable"<br />
! Method<br />
! Articles<br />
! Conditions<br />
|-<br />
| Write the image on flash media or optical disc, then boot from it.<br />
|<br />
* [[USB flash installation media]]<br />
* [[Optical disc drive#Burning]]<br />
|<br />
* Installation on one, or a few machines at most<br />
* Obtain a directly bootable system<br />
|-<br />
| Mount the image on a server machine and have clients boot it over the network.<br />
|<br />
* [[PXE]]<br />
* [[Diskless system]]<br />
|<br />
* Client-server model<br />
* Wired (1Gbit+) network connection<br />
|-<br />
| Mount the image in a running Linux system and install Arch from a chroot environment.<br />
|<br />
* [[Install from existing Linux]]<br />
* [[Install from SSH]]<br />
|<br />
* Replace an existing system with reduced downtime<br />
* Install on the local machine, or a remote one via [[VNC]] or [[SSH]]<br />
|-<br />
| Set up a virtual machine and install Arch as a guest system.<br />
|<br />
* [[:Category:Hypervisors]]<br />
* [[Moving an existing install into (or out of) a virtual machine]]<br />
|<br />
* Operating system compatible with virtualization software<br />
* Obtain an isolated system for learning, testing or debugging<br />
|}<br />
<br />
== Boot the installation medium ==<br />
<br />
Point the current boot device to the media containing the Arch installation media. This is typically achieved by pressing a key during the [[Wikipedia:Power-on self test|POST]] phase, as indicated on the splash screen. Refer to your motherboard's manual for details.<br />
<br />
When the Arch menu appears, select "Boot Arch Linux" and press {{ic|Enter}} to enter the live environment where you will perform the actual installation. Various boot parameters (for example, {{ic|copytoram}}) can be used by editing the boot entry ({{ic|tab}} for syslinux and {{ic|e}} for gummiboot), see [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams README.bootparams] for reference.<br />
<br />
You will be presented with a [[Zsh]] shell prompt, logged in as the root user. ''Zsh'' provides advanced tab completion and other features as part of the [http://grml.org/zsh/ grml config]. For editing text files, the console editor [[nano#Usage|nano]] is suggested.<br />
<br />
=== Booting into UEFI mode ===<br />
<br />
{{Warning|While the choice to install in EFI mode is forward looking, early vendor UEFI implementations carried more bugs than their BIOS counterparts. It is advised to do a search relating your particular mainboard model before proceeding.}}<br />
<br />
In case you have a [[Unified Extensible Firmware Interface|UEFI]] motherboard with UEFI mode enabled, the CD/USB will automatically launch Arch Linux via [[Gummiboot]] and present the following menu:<br />
<br />
{{bc|<br />
Arch Linux archiso x86_64 UEFI USB<br />
UEFI Shell x86_64 v1<br />
UEFI Shell x86_64 v2<br />
EFI Default Loader}}<br />
<br />
To verify you are booted in UEFI mode, run:<br />
<br />
# efivar -l<br />
<br />
Should ''efivar'' not list the UEFI variables properly, check if all [[UEFI#Requirements_for_UEFI_variable_support|requirements]] are met.<br />
<br />
=== Troubleshooting boot problems ===<br />
<br />
* If you are using an Intel video chipset and the screen goes blank during the boot process, the problem is likely an issue with [[Kernel mode setting]]. A possible workaround may be achieved by rebooting and pressing {{ic|Tab}} over the entry that you are trying to boot (i686 or x86_64). At the end of the string type {{ic|nomodeset}} and press {{ic|Enter}}. Alternatively, try {{ic|1=video=SVIDEO-1:d}} which, if it works, will not disable kernel mode setting. You can also try {{ic|1=i915.modeset=0}}. See the [[Intel]] article for more information.<br />
* If the screen does ''not'' go blank and the boot process gets stuck while trying to load the kernel, press {{ic|Tab}} while hovering over the menu entry, type {{ic|1=acpi=off}} at the end of the string and press {{ic|Enter}}.<br />
<br />
== Keyboard layout ==<br />
<br />
{{Note|Changes here ''only'' affect the installation process.}}<br />
<br />
The default keyboard layout is set to [[Wikipedia:File:KB United States-NoAltGr.svg|US]], the [[locale]] to {{ic|en_US.UTF-8}}. To change the keyboard layout, run:<br />
<br />
# loadkeys ''layout''<br />
<br />
where ''layout'' is a two-letter [[Wikipedia:ISO 3166-1 alpha-2#Officially assigned code elements|country code]]. Use {{ic|localectl list-keymaps}} to list all available keymaps.<br />
<br />
If certain special characters appear as white squares or other symbols, you may wish to change the console font. See [[Fonts#Previewing_and_testing]] for details.<br />
<br />
== Establish an internet connection ==<br />
<br />
{{Warning|As of [http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id&#61;dee4c244254bb49d1ffa8bd7171ae9cce596d2d0 v197], udev no longer assigns network interface names according to the ''wlanX'' and ''ethX'' naming scheme. If you are coming from a different distribution or are reinstalling Arch and not aware of the new interface naming style, please do not assume that your wireless interface is named ''wlan0'', or that your wired interface is named ''eth0''. You can use the command {{ic|ip link}} to discover the names of your interfaces.}}<br />
<br />
The ''dhcpcd'' network daemon starts automatically during boot of the live system and will attempt to start a wired connection. Try to ping a server to see if a connection was established. For example, Google's webservers:<br />
<br />
{{hc|# ping -c 3 www.google.com|2=<br />
PING www.l.google.com (74.125.132.105) 56(84) bytes of data.<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=1 ttl=50 time=17.0 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=2 ttl=50 time=18.2 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=3 ttl=50 time=16.6 ms<br />
<br />
--- www.l.google.com ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2003ms<br />
rtt min/avg/max/mdev = 16.660/17.320/18.254/0.678 ms<br />
}}<br />
<br />
If you get a {{ic|ping: unknown host}} error, first check if there is an issue with your cable. If not, you will need to set up the network manually, as explained below. Once a connection is established move on to [[#Prepare the storage devices]].<br />
<br />
{{Tip|<br />
* The ''elinks'' browser is available in the live system: it can be useful for example to authenticate in RADIUS-protected networks. <br />
* The system you are going to install in this guide makes no pre-assumptions regarding network access. For an easy start after the first boot, it may be helpful to stick to the method that got you connected with the live medium and copy relevant configuration to the new system before you [[#Chroot and configure the base system]] later.}}<br />
<br />
=== Static IP ===<br />
<br />
Follow this procedure if you need to set up a wired connection via a static IP address.<br />
<br />
Identify the name of your ethernet interface:<br />
<br />
{{hc|# ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp2s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000<br />
link/ether 00:11:25:31:69:20 brd ff:ff:ff:ff:ff:ff<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000<br />
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
In this example, the ethernet interface is {{ic|enp2s0f0}}. If you are unsure, your ethernet interface is likely to start with the letter "e", and unlikely to be "lo" or start with the letter "w".<br />
<br />
See [[Network_configuration#Static_IP_address]] for required settings. Configure a static profile for ''dhcpcd'' in {{ic|/etc/dhcpcd.conf}} with your settings, for example: <br />
<br />
interface enp2s0f0<br />
static ip_address=192.168.0.10/24<br />
static routers=192.168.0.1<br />
static domain_name_servers=192.168.0.1 8.8.8.8<br />
<br />
Restart {{ic|dhcpcd.service}}:<br />
<br />
# systemctl restart dhcpcd.service<br />
<br />
You should now have a working network connection. If you do not, see [[Network configuration]] page.<br />
<br />
=== Wireless ===<br />
<br />
{{Warning|Wireless chipset firmware packages (for cards which require them) are pre-installed under {{ic|/usr/lib/firmware}} in the live environment (on CD/USB stick) '''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!''' Package installation is covered later in this guide. Ensure installation of both your wireless module and firmware before rebooting! See [[Wireless network configuration]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset.}}<br />
<br />
Use [[netctl]]'s ''wifi-menu'' to connect to a wireless network:<br />
<br />
# wifi-menu<br />
<br />
This should bring you a menu of wifi networks if your computer has only one Wi-Fi device (mostly the case in laptops).<br />
<br />
If your computer has more than one Wi-Fi device, you need to choose one and pass its interface name to ''wifi-menu''. First, identify the name of the needed interface:<br />
<br />
{{hc|# iw dev|2=<br />
phy#0<br />
Interface wlp3s0<br />
ifindex 3<br />
wdev 0x1<br />
addr 00:11:22:33:44:55<br />
type managed<br />
}}<br />
<br />
This example shows {{ic|wlp3s0}} as the only available wireless interface, for simplicity. If you are unsure, wireless interfaces are likely to start with the letter "w", and unlikely to be "lo" or start with the letter "e".<br />
<br />
Now try ''wifi-menu'' again by passing it the interface name:<br />
<br />
# wifi-menu wlp3s0<br />
<br />
See the sample configuration in [[WPA2 Enterprise#netctl]] for networks that require both a username and password.<br />
<br />
You should now have a working wireless network connection. If you do not or even failed to identify the wireless interface, see [[#Without wifi-menu]] below or the detailed [[Wireless network configuration]] page.<br />
<br />
==== Without wifi-menu ====<br />
<br />
Bring the interface up with:<br />
<br />
# ip link set wlp3s0 up<br />
<br />
To verify that the interface is up, inspect the output of the following command:<br />
<br />
{{hc|# ip link show wlp3s0|<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000<br />
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
The {{ic|UP}} in {{ic|<BROADCAST,MULTICAST,UP,LOWER_UP>}} is what indicates the interface is up, not the later {{ic|state DOWN}}.<br />
<br />
Most wireless chipsets require firmware in addition to a corresponding driver. The kernel tries to identify and load both automatically. If you get output like {{ic|SIOCSIFFLAGS: No such file or directory}}, this means you will need to manually load the firmware. If unsure, invoke ''dmesg'' to query the kernel log for a firmware request from the wireless chipset. For example, if you have an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
<br />
{{hc|<nowiki># dmesg | grep firmware</nowiki>|<br />
firmware: requesting iwlwifi-5000-1.ucode<br />
}}<br />
<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
Next, scan for available networks using {{ic|iw dev wlp3s0 scan <nowiki>|</nowiki> grep SSID}}, then connect to a network with:<br />
<br />
# wpa_supplicant -B -i wlp3s0 -c <(wpa_passphrase "''ssid''" "''psk''")<br />
<br />
You need to replace {{ic|''ssid''}} with the name of your network and {{ic|''psk''}} with your wireless password, '''leaving the quotes around the network name and password'''.<br />
<br />
Finally, you have to give your interface an IP address. This can be set manually or using dhcp:<br />
<br />
# dhcpcd wlp3s0<br />
<br />
If that does not work, issue the following commands:<br />
<br />
# echo 'ctrl_interface=DIR=/run/wpa_supplicant' > /etc/wpa_supplicant.conf<br />
# wpa_passphrase "''ssid''" "''psk''" >> /etc/wpa_supplicant.conf<br />
# ip link set ''interface'' up<br />
# wpa_supplicant -B -D nl80211,wext -c /etc/wpa_supplicant.conf -i ''interface''<br />
# dhcpcd -A ''interface''<br />
<br />
Setting the interface up at step 3 may not be needed, but does no harm in any case.<br />
<br />
=== Analog modem, ISDN, or PPPoE DSL ===<br />
<br />
For xDSL, dial-up, and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Behind a proxy server ===<br />
<br />
If you are behind a proxy server, you will need to export the {{ic|http_proxy}} and {{ic|ftp_proxy}} environment variables. See [[Proxy settings]] for more information.<br />
<br />
== Prepare the storage devices ==<br />
<br />
In this step, the storage devices that will be used by the new system will be prepared. Read [[Partitioning]] for a more general overview.<br />
<br />
{{Warning|Partitioning will destroy existing data. Before proceeding, you '''must''' backup all data that needs to be preserved.}}<br />
<br />
{{Tip|<br />
* Users intending to create stacked block devices for [[LVM]], [[disk encryption]] or [[RAID]], should keep those instructions into consideration when preparing the partitions.<br />
* If intending to install to a USB flash key, see [[Installing Arch Linux on a USB key]].}}<br />
<br />
=== Identify the devices ===<br />
<br />
The first step is to identify the devices where the new system will be installed. The following command will show all the available devices:<br />
<br />
# lsblk<br />
<br />
This will list all devices connected to your system along with their partition schemes, including that used to host and boot live Arch installation media (e.g. a USB drive). Not all devices listed will therefore be viable or appropriate mediums for installation. To filter out inappropriate results, the command can optionally be amended as follows:<br />
<br />
# lsblk | grep -v "rom\|loop\|airoot"<br />
<br />
Devices (e.g. hard disks) will be listed as {{ic|sd''x''}}, where {{ic|''x''}} is a lower-case letter starting from {{ic|a}} for the first device ({{ic|sda}}), {{ic|b}} for the second device ({{ic|sdb}}), and so on. Existing partitions on those devices will be listed as {{ic|sd''xY''}}, where {{ic|''Y''}} is a number starting from {{ic|1}} for the first partition, {{ic|2}} for the second, and so on. In the example below, only one device is available ({{ic|sda}}), and that device uses only one partition ({{ic|sda1}}):<br />
<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sda 8:0 0 80G 0 disk<br />
└─sda1 8:1 0 80G 0 part<br />
<br />
The {{ic|sd''xY''}} convention will be used in the examples provided below for partition tables, partitions, and file systems. As they are just examples, it is important to ensure that any necessary changes to device names, partition numbers, and/or partition sizes (etc.) are made. Do not just blindly copy and paste the commands.<br />
<br />
If the existing partition scheme needs not be changed, skip to [[#Create filesystems]], otherwise continue reading the following section.<br />
<br />
=== Partition table types ===<br />
<br />
If you are installing alongside an existing installation (i.e. dual-booting), a partition table will already be in use. If the devices are not partitioned, or the current partitions table or scheme needs to be changed, you will first have to determine the partition tables (one for each device) in use or to be used.<br />
<br />
{{Warning|If Arch and Windows are dual-booting from same device, then Arch '''must''' follow the same firmware boot mode and partitioning combination already used, or Windows will fail to boot. See [[Windows and Arch Dual Boot#Important information]] for more details.}}<br />
<br />
There are two types of partition table:<br />
<br />
* [[Master Boot Record| MBR]]: Intended for BIOS systems (also referred to as "msdos")<br />
* [[GUID Partition Table| GPT]]: Intended for UEFI systems<br />
<br />
Any existing partition table can be identified with the following command for each device:<br />
<br />
# parted /dev/sd''x'' print<br />
<br />
=== Partitioning tools ===<br />
<br />
For each device to be partitioned, a proper tool must be chosen according to the partition table to be used. Several partitioning tools are provided by the Arch installation medium, including:<br />
<br />
* [[parted]]: MBR and GPT<br />
* [[Partitioning#Fdisk usage summary|fdisk]], '''cfdisk''', '''sfdisk''': MBR and GPT<br />
* [[Partitioning#Gdisk usage summary|gdisk]], '''cgdisk''', '''sgdisk''': GPT<br />
<br />
{{Warning|Using a partitioning tool that is incompatible with your partition table type will likely result in the destruction of that table, along with any existing partitions/data.}}<br />
<br />
{{Tip|The devices may also be partitioned before booting the Arch installation media, possibly using alternative live systems with other partitioning tools. For example beginners might find it easier to use a graphical partitioning tool such as [[GParted]], which is also provided as a [http://gparted.sourceforge.net/livecd.php live CD] and works with both MBR and GPT partition tables.}}<br />
<br />
==== Using parted in interactive mode ====<br />
<br />
All the examples provided below make use of ''parted'', as it can be used for both BIOS/MBR and UEFI/GPT. It will be launched in ''interactive mode'', which simplifies the partitioning process and reduces unnecessary repetition by automatically applying all partitioning commands to the specified device.<br />
<br />
In order to start operating on a device, execute:<br />
<br />
# parted /dev/sd''x''<br />
<br />
You will notice that the command-line prompt changes from a hash ({{ic|#}}) to {{ic|(parted)}}: this also means that the new prompt is not a command to be manually entered when running the commands in the examples.<br />
<br />
To see a list of the available commands, enter:<br />
<br />
(parted) help<br />
<br />
When finished, or if wishing to implement a partition table or scheme for another device, exit from parted with:<br />
<br />
(parted) quit<br />
<br />
After exiting, the command-line prompt will change back to {{ic|#}}.<br />
<br />
=== Create new partition table ===<br />
<br />
You need to (re)create the partition table of a device when it has never been partitioned before, or when you want to change the type of its partition table. Recreating the partition table of a device is also useful when the partition scheme needs to be restructured from scratch.<br />
<br />
{{Warning|<br />
* If dual-booting with an existing installation of Windows on a UEFI/GPT system, do not erase the partition table. Doing so will destroy all existing data on the device, including the UEFI partition with the Windows ''.efi'' file required to boot it.<br />
* MBR is designed specifically for use with BIOS systems, and GPT is designed for UEFI. It is not recommended for less experienced users to break this convention as both have features and/or limitations that may be incompatible with your hardware (e.g. MBR cannot cope with devices larger than 2 TiB). [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/] If for any reason you do not wish to follow this convention, see [http://mjg59.dreamwidth.org/8035.html] and [http://rodsbooks.com/gdisk/bios.html] for more information and possible workarounds.}}<br />
<br />
Open each device whose partition table must be (re)created with:<br />
<br />
# parted /dev/sd''x''<br />
<br />
To then create a new MBR/msdos partition table for BIOS systems, use the following command:<br />
<br />
(parted) mklabel msdos<br />
<br />
To create a new GPT partition table for UEFI systems instead, use:<br />
<br />
(parted) mklabel gpt<br />
<br />
=== Partition schemes ===<br />
<br />
You can decide the number and size of the partitions the devices should be split into, and which directories will be used to mount the partitions in the installed system (also known as ''mount points''). The mapping from partitions to directories is the [[Partitioning#Partition scheme|partition scheme]], which must comply with the following requirements:<br />
<br />
* At least a partition for the {{ic|/}} (''root'') directory '''must''' be created.<br />
* Depending on the motherboard's firmware interface, the chosen [[#Partition table types]], and in some cases also the chosen [[boot loader]], the following additional partitions '''must''' be created:<br />
** '''BIOS/MBR''': no additional partition required.<br />
** '''UEFI/GPT''': one [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]].<br />
<br />
In the examples below it is assumed that a new and contiguous partitioning scheme is applied to a single device. Some optional partitions will also be created for the {{ic|/boot}} and {{ic|/home}} directories: see also [[Arch filesystem hierarchy]] for an explanation of the purpose of the various directories; if separate partitions for directories like {{ic|/boot}} or {{ic|/home}} are not created, these will simply be contained in the {{ic|/}} partition. Also the creation of an optional partiton for [[swap space]] will be illustrated.<br />
<br />
If not already open in a ''parted'' interactive session, open each device to be partitioned with:<br />
<br />
# parted /dev/sd''x''<br />
<br />
The following command will be used to create partitions:<br />
<br />
(parted) mkpart ''part-type'' ''fs-type'' ''start'' ''end''<br />
<br />
* {{ic|''part-type''}} is one of {{ic|primary}}, {{ic|extended}} or {{ic|logical}}, and is meaningful only for MBR partition tables.<br />
* {{ic|''fs-type''}} is an identifier chosen among those listed by entering {{ic|help mkpart}} as the closest match to the file system that you will use in [[#Create filesystems]]. The ''mkpart'' command does not actually create the file system: the {{ic|''fs-type''}} parameter will simply be used by ''parted'' to set a 1-byte code that is used by boot loaders to "preview" what kind of data is found in the partition, and act accordingly if necessary. See also [[Wikipedia:Disk partitioning#PC partition types]].<br />
: {{Tip|Most [[Wikipedia:File_system#Linux|Linux native file systems]] map to the same partition code ([[Wikipedia:Partition type#PID_83h|0x83]]), so it is perfectly safe to e.g. use {{ic|ext2}} for an ''ext4''-formatted partition.}}<br />
* {{ic|''start''}} is the beginning of the partition from the start of the device. It consists of a number followed by a [http://www.gnu.org/software/parted/manual/parted.html#unit unit], for example {{ic|1M}} means start at 1MiB.<br />
* {{ic|''end''}} is the end of the partition from the start of the device (''not'' from the {{ic|''start''}} value). It has the same syntax as {{ic|''start''}}, for example {{ic|100%}} means end at the end of the device (use all the remaining space).<br />
<br />
{{Warning|It is important that the partitions do not overlap each other: if you do not want to leave unused space in the device, make sure that each partition starts where the previous one ends.}}<br />
<br />
{{Note|''parted'' may issue a warning like:<br />
<br />
Warning: The resulting partition is not properly aligned for best performance.<br />
Ignore/Cancel?<br />
<br />
In this case, read [[Partitioning#Partition alignment]] and follow [[GNU Parted#Alignment]] to fix it.}}<br />
<br />
The following command will be used to flag the partition that contains the {{ic|/boot}} directory as bootable:<br />
<br />
(parted) set ''partition'' boot on<br />
<br />
* {{ic|''partition''}} is the number of the partition to be flagged (see the output of the {{ic|print}} command).<br />
<br />
==== UEFI/GPT examples ====<br />
<br />
In every instance, a special bootable [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] is required.<br />
<br />
{{Warning|If dual-booting with an existing installation of Windows on a UEFI/GPT system, the existing UEFI partition must not be deleted. Doing so will destroy the ''.efi'' file required to boot Windows.}}<br />
<br />
If creating a new EFI System Partition, use the following commands (the recommended size is 512MiB):<br />
<br />
(parted) mkpart ESP fat32 1MiB 513MiB<br />
(parted) set 1 boot on<br />
<br />
The remaining partition scheme is entirely up to you. For one other partition using 100% of remaining space:<br />
<br />
(parted) mkpart primary ext3 513MiB 100%<br />
<br />
For separate {{ic|/}} (20GiB) and {{ic|/home}} (all remaining space) partitions:<br />
<br />
(parted) mkpart primary ext3 513MiB 20.5GiB<br />
(parted) mkpart primary ext3 20.5GiB 100%<br />
<br />
And for separate {{ic|/}} (20GiB), swap (4GiB), and {{ic|/home}} (all remaining space) partitions:<br />
<br />
(parted) mkpart primary ext3 513MiB 20.5GiB<br />
(parted) mkpart primary linux-swap 20.5GiB 24.5GiB<br />
(parted) mkpart primary ext3 24.5GiB 100%<br />
<br />
==== BIOS/MBR examples ====<br />
<br />
For a minimum single primary partition using all available disk space, the following command would be used:<br />
<br />
(parted) mkpart primary ext3 1MiB 100%<br />
(parted) set 1 boot on<br />
<br />
In the following instance, a 20GiB {{ic|/}} partition will be created, followed by a {{ic|/home}} partition using all the remaining space:<br />
<br />
(parted) mkpart primary ext3 1MiB 20GiB<br />
(parted) set 1 boot on<br />
(parted) mkpart primary ext3 20GiB 100%<br />
<br />
In the final example below, separate {{ic|/boot}} (100MiB), {{ic|/}} (20GiB), swap (4GiB), and {{ic|/home}} (all remaining space) partitions will be created:<br />
<br />
(parted) mkpart primary ext3 1MiB 100MiB<br />
(parted) set 1 boot on<br />
(parted) mkpart primary ext3 100MiB 20GiB<br />
(parted) mkpart primary linux-swap 20GiB 24GiB<br />
(parted) mkpart primary ext3 24GiB 100%<br />
<br />
=== Create filesystems ===<br />
<br />
Once the partitions have been created, each must be formatted with an appropriate [[file system]], ''except'' for swap partitions. All available partitions on the intended installation device can be listed with the following command:<br />
<br />
# lsblk /dev/sd''x''<br />
<br />
With the exceptions noted below, it is recommended to use the {{ic|ext4}} file system:<br />
<br />
# mkfs.ext4 /dev/sd''xY''<br />
<br />
{{Warning|<br />
* If dual-booting with an existing installation of Windows on a UEFI/GPT system, do not re-format the UEFI partition. Doing so will destroy all existing data on that partition, including the Windows ''.efi'' file required to boot it.<br />
* If a new UEFI system partition has been created on a UEFI/GPT system, it must be formatted with a {{ic|fat32}} or {{ic|vfat32}} file system. Failure to do so will result in an unbootable installation:<br />
:{{bc|# mkfs.vfat -F32 /dev/sd''xY''}}}}<br />
<br />
=== Activate swap ===<br />
<br />
If a swap partition has been created, it must be set up and activated with:<br />
<br />
# mkswap /dev/sd''xY''<br />
# swapon /dev/sd''xY''<br />
<br />
=== Mount the partitions ===<br />
<br />
{{Note|Swap partitions must '''not''' be mounted here.}}<br />
<br />
The {{ic|/}} (root) partition must be mounted '''first''': this is because any directories such as {{ic|/boot}} or {{ic|/home}} that have separate partitions will have to be created in the root file system. The {{ic|/mnt}} directory of the live system will be used to mount the root partition, and consequently all the other partitions will stem from there. If the root partition's name is {{ic|sd''xR''}}, do:<br />
<br />
# mount /dev/sd''xR'' /mnt<br />
<br />
Once the {{ic|/}} partition has been mounted, any remaining partitions may be mounted in any order. The general procedure is to first create the mount point, and then mount the partition to it. If using a separate {{ic|/boot}} partition:<br />
<br />
# mkdir -p /mnt/boot<br />
# mount /dev/sd''xB'' /mnt/boot<br />
<br />
{{Note|Using {{ic|/boot}} is recommended also for mounting the EFI System Partition on UEFI/GPT system. See [[EFISTUB]] and related articles for alternatives.}}<br />
<br />
If using a separate {{ic|/home}} partition:<br />
<br />
# mkdir -p /mnt/home<br />
# mount /dev/sd''xH'' /mnt/home<br />
<br />
Once all the remaining partitions, if any, have been mounted, the devices are ready to install Arch.<br />
<br />
== Select a mirror ==<br />
<br />
You may want to edit the {{ic|mirrorlist}} file and place your preferred mirror first. A copy of this file will be installed on your new system by ''pacstrap'' as well, so it is worth getting it right.<br />
<br />
{{hc|# nano /etc/pacman.d/mirrorlist|<br />
##<br />
## Arch Linux repository mirrorlist<br />
## Sorted by mirror score from mirror status page<br />
## Generated on YYYY-MM-DD<br />
##<br />
<br />
<nowiki>Server = http://mirror.example.xyz/archlinux/$repo/os/$arch</nowiki><br />
...}}<br />
<br />
If you want, you can make it the ''only'' mirror available by deleting all other lines, but it is usually a good idea to have a few more, in case the first one goes offline. Should you change your mirror list at a later stage, refresh all package lists with {{ic|pacman -Syyu}}. See [[Mirrors]] for more information.<br />
<br />
== Install the base system ==<br />
<br />
The base system is installed using the ''pacstrap'' script. Without the {{ic|-i}} switch, every package from the {{Grp|base}} [[Pacman#Installing_package_groups|group]] is installed without prompting. To build packages from the [[AUR]] or with [[ABS]], you will also need the {{Grp|base-devel}} group.<br />
<br />
# pacstrap -i /mnt base base-devel<br />
<br />
Other packages can be installed later using [[pacman]].<br />
<br />
See [[Pacman#Troubleshooting]] and [[Pacman-key#Troubleshooting]] in case of errors.<br />
<br />
== Generate an fstab ==<br />
<br />
[[Wikipedia:Universally_unique_identifier|UUID]]s are used because they have certain advantages (see [[fstab#Identifying filesystems]]). If you prefer labels instead, replace the {{ic|-U}} option with {{ic|-L}}:<br />
<br />
# genfstab -U -p /mnt >> /mnt/etc/fstab<br />
# cat /mnt/etc/fstab<br />
<br />
{{Warning|The {{ic|fstab}} file should always be checked after generating it. If you encounter errors running ''genfstab'' or later in the install process, do '''not''' run ''genfstab'' again; just edit the {{ic|fstab}} file. See [[fstab#Field definitions]] for syntax information.}}<br />
<br />
== Chroot and configure the base system ==<br />
<br />
Next, [[Change root|chroot]] into your newly installed system:<br />
<br />
# arch-chroot /mnt /bin/bash<br />
<br />
At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system. These can either be created if they do not exist, or edited if you wish to change the defaults.<br />
<br />
Closely following and understanding these steps is of key importance to ensure a properly configured system.<br />
<br />
{{Warning|Do not assume that the tools you used from the ISO are automatically installed. For example, if you used ''wifi-menu'' to gain network access during the installation and want to continue so after the first boot, you will have to install ''dialog'' to use it. The following section specifies such cases, do follow it closely to avoid a hiccup in your fresh install.}}<br />
<br />
=== Locale ===<br />
<br />
Locales define which language the system uses and other regional considerations, such as currency denomination, numerology and character sets. Possible values are listed in {{ic|/etc/locale.gen}}, with the active locale defined in {{ic|locale.conf}} files.<br />
<br />
All entries in {{ic|locale.gen}} are commented out (preceded by {{ic|#}}) by default. Uncomment {{ic|en_US.UTF-8 UTF-8}}, as well as other needed localisations. {{ic|UTF-8}} is highly recommended over other options.<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
...<br />
#en_SG ISO-8859-1<br />
en_US.UTF-8 UTF-8<br />
#en_US ISO-8859-1<br />
...<br />
}}<br />
<br />
Before locales can be enabled, they must be ''generated'':<br />
<br />
# locale-gen<br />
<br />
Create {{ic|/etc/locale.conf}}, where {{ic|LANG}} refers to the first column of an uncommented entry in {{ic|/etc/locale.gen}}.<br />
<br />
# echo LANG=''en_US.UTF-8'' > /etc/locale.conf<br />
<br />
Export the chosen locale:<br />
<br />
# export LANG=''en_US.UTF-8''<br />
<br />
{{Note|<br />
* Choosing {{ic|en_US.UTF-8}} as the system locale allows to keep system logs in English for easier troubleshooting. Users may override this setting for their session as described in [[Locale#Setting the locale]].<br />
* {{ic|LANG}} acts as the default value for the locale-related {{ic|LC_*}} variables. To use other locales for these variables, run ''locale'' to see the available options and add them to {{ic|locale.conf}}. It is not recommended to set the {{ic|LC_ALL}} variable. See [[Locale]] for details.}}<br />
<br />
=== Console font and keymap ===<br />
<br />
If you changed the default console keymap and font in [[#Keyboard layout]], create {{ic|/etc/vconsole.conf}} to make those changes persist in the installed system. It is important {{ic|KEYMAP}} matches the value initially set with {{ic|loadkeys}}, to ensure correct entry of [[#Set the root password|the root password]] on reboot.<br />
<br />
{{hc|# nano /etc/vconsole.conf|2=<br />
KEYMAP=''de-latin1''<br />
FONT=''lat9w-16''<br />
}}<br />
<br />
These settings only apply to virtual consoles, not [[Xorg]]. See [[Fonts#Console fonts]] for more information.<br />
<br />
=== Time zone ===<br />
<br />
Available time zones and subzones can be found in the {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}} directories, and listed with the ''ls'' command. Create a symbolic link {{ic|/etc/localtime}} to your subzone file {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}}:<br />
<br />
# ln -s /usr/share/zoneinfo/''Zone''/''SubZone'' /etc/localtime<br />
<br />
You may use [http://tldp.org/LDP/abs/html/tabexpansion.html tab completion] to show available zones and subzones. Example:<br />
<br />
# ln -s /usr/share/zoneinfo/Europe/Minsk /etc/localtime<br />
<br />
If you get {{ic|ln: failed to create symbolic link '/etc/localtime': File exists}}, check the existing file with {{ic|ls -l /etc/localtime}} and add the {{ic|-f}} option to the ''ln'' command to overwrite it.<br />
<br />
=== Hardware clock ===<br />
<br />
If you have multiple operating systems installed in the same machine, they will all derive the current time from the same hardware clock, which must be set to either UTC or ''localtime''. For this reason you must make sure that all the operating systems see the hardware clock as providing time in the same chosen [[Time#Time standard|standard]], otherwise some of them will perform the time zone adjustement for the system clock, while others will not.<br />
<br />
In particular, it is strongly recommended to set the hardware clock to UTC, in order to avoid conflicts between the installed operating systems. For example, if the hardware clock was set to ''localtime'', more than one operating system may adjust it after a [[Wikipedia:Daylight_saving_time|DST]] change, thus resulting in an overcorrection; more problems may arise when travelling between different time zones and using one of the operating systems to reset the system/hardware clock.<br />
<br />
To set the hardware clock to UTC in Linux, run:<br />
<br />
# hwclock --systohc --utc<br />
<br />
The ''hwclock'' command also generates the {{ic|/etc/adjtime}} file.<br />
<br />
{{Note|Using UTC for the hardware clock does not mean that software will display time in UTC. However, the system setup/BIOS interface will instead: this should be neither surprising nor treated as a bug.}}<br />
<br />
{{Warning|Windows systems use ''localtime'' by default. Using ''localtime'' on Arch systems may lead to several known and unfixable bugs, but there are no plans to drop support for ''localtime''. It is, though, recommended to set Windows to use UTC instead, and prevent it from synchronising time. See [[Time#UTC in Windows]].}}<br />
<br />
=== Kernel modules ===<br />
<br />
Needed kernel modules are automatically loaded by [[udev]], so you will rarely need to load modules manually. See [[Kernel modules]] for details.<br />
<br />
=== Hostname ===<br />
<br />
Set the [[Network_configuration#Set_the_hostname|hostname]] to your liking:<br />
<br />
# echo ''myhostname'' > /etc/hostname<br />
<br />
=== Configure the network ===<br />
<br />
You need to configure the network again, but this time for your newly installed environment. The procedure and prerequisites are similar to the one described [[#Establish an internet connection|above]], except we are going to make it persistent and automatically run at boot.<br />
<br />
As a first step, identify the network interface name you want to configure the connection for with {{ic|ip link}}.<br />
<br />
{{Note|<br />
* For more in-depth information on network configuration, visit [[Network configuration]] and [[Wireless network configuration]].<br />
* If you would like to use the old interface naming scheme (i.e. {{ic|eth''X''}} and {{ic|wlan''X''}}) you can accomplish this by creating an empty file at {{ic|/etc/udev/rules.d/80-net-setup-link.rules}} which will mask the file of the same name located under {{ic|/usr/lib/udev/rules.d}}.<br />
}}<br />
<br />
Now select a daemon to handle the configuration and operation. Several are listed below; only select '''one''' of them for the new system.<br />
<br />
==== Wired ====<br />
<br />
; Using dhcpcd<br />
A simple option for adapter configuration is to use the DHCP Client Daemon, the method used by default with the install medium. See [[Dhcpcd#Running]].<br />
<br />
Users requiring only '''single wired network connection''' can simply enable the ''dhcpcd'' service for the interface:<br />
<br />
# systemctl enable dhcpcd@''interface_name''.service<br />
<br />
If static IP settings are required, adjust the profile configuration as described in [[#Static IP]]. <br />
<br />
; Using systemd-networkd<br />
<br />
The Arch default init system, [[systemd]] includes built-in support for managing adapters using both DHCP and static IP setups. Configuration is simple. See [[Systemd-networkd#Required_services_and_setup]].<br />
<br />
; Using netctl<br />
<br />
Another option is [[netctl]] which is a CLI-based tool used to configure and manage network connections via user-created profiles. Create a profile as shown in [[netctl#Example profiles]], then enable it as described in [[netctl#Basic method]].<br />
<br />
==== Wireless ====<br />
<br />
All of the tools listed in [[#Wired]] above can activate wireless connections. For wireless, however, ''dhcpcd'' and ''systemd-networkd'' require a separate configuration of the connection in the wireless backend, [[wpa_supplicant]], first. If you anticipate to connect the machine to different wireless networks over time, a tool which provides its own connection management may be easier to handle. Aside from [[netctl]] introduced below, [[Wireless network configuration#Automatic setup]] lists other choices. <br />
<br />
{{Note|If your wireless adapter requires a firmware (as described in the above [[#Wireless|Establish an internet connection]] section and also in the article [[Wireless network configuration#Device driver]]), install the package containing your firmware. Most of the time, the {{Pkg|linux-firmware}} package will contain the needed firmware. Though for some devices, the required firmware might be in its own package. For example:<br />
{{bc|# pacman -S zd1211-firmware}}<br />
See [[Wireless network configuration#Installing driver/firmware]] for more info.}}<br />
<br />
Install {{Pkg|iw}} and {{Pkg|wpa_supplicant}} which you will need to connect to a network:<br />
<br />
# pacman -S iw wpa_supplicant<br />
<br />
===== Adding wireless networks =====<br />
<br />
; Using wifi-menu<br />
<br />
Install {{Pkg|dialog}}, which is required for ''wifi-menu'':<br />
<br />
# pacman -S dialog<br />
<br />
After finishing the rest of this installation and rebooting, you can connect to the network with:<br />
<br />
# wifi-menu ''interface_name''<br />
<br />
Where {{ic|''interface_name''}} is the interface of your wireless chipset.<br />
<br />
{{Warning|Do not use ''wifi-menu'' now, instead wait until you have finished this guide and have rebooted. It will not work now because a process spawned by this command will conflict with the one you have running outside of the chroot. Alternatively, you could just configure a network profile manually using the following templates so that you do not have to worry about using ''wifi-menu'' at all.}}<br />
<br />
; Using manual netctl profiles<br />
<br />
Copy a network profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/wireless-wpa my-network<br />
<br />
Edit the profile as needed (modify {{ic|Interface}}, {{ic|ESSID}} and {{ic|Key}}):<br />
<br />
# nano my-network<br />
<br />
Enable above created profile to start it at every boot:<br />
<br />
# netctl enable my-network<br />
<br />
===== Connect automatically to known networks =====<br />
<br />
{{Warning|This method cannot be used with explicitely enabled [[Netctl#Configuration|profiles]], i.e. through {{ic|netctl enable ''profile''}}.}}<br />
<br />
Install {{Pkg|wpa_actiond}}, which is required for {{ic|netctl-auto}}:<br />
<br />
# pacman -S wpa_actiond<br />
<br />
Enable the {{ic|netctl-auto}} service, which will connect to known networks and gracefully handle roaming and disconnects:<br />
<br />
# systemctl enable netctl-auto@''interface_name''.service<br />
<br />
{{Tip|[[netctl]] also provides {{ic|netctl-ifplugd}}, which can be used to handle wired profiles in conjunction with {{ic|netctl-auto}}.}}<br />
<br />
==== Analog modem, ISDN or PPPoE DSL ====<br />
<br />
For xDSL, dial-up and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Create an initial ramdisk environment ===<br />
<br />
As [[mkinitcpio]] was run on installation of {{Pkg|linux}} with ''pacstrap'', most users can use the defaults provided in {{ic|mkinitcpio.conf}}. For special configurations, set the correct [[Mkinitcpio#HOOKS|hooks]] in {{ic|/etc/mkinitcpio.conf}} and [[Mkinitcpio#Image_creation_and_activation|re-generate the initramfs image]].<br />
<br />
=== Set the root password ===<br />
<br />
Set the root password with:<br />
<br />
# passwd<br />
<br />
=== Install and configure a bootloader ===<br />
<br />
See [[Boot loaders]] for available choices and configurations. [[Microcode]] updates for Intel CPUs must also be configured after installing the boot loader.<br />
<br />
==== For BIOS motherboards ====<br />
<br />
Here, installation with '''GRUB''' and '''MBR''' is demonstrated. <br />
<br />
Install the {{Pkg|grub}} package; to have GRUB search for other installed operating systems, install {{Pkg|os-prober}} in addition:<br />
<br />
# pacman -S grub os-prober<br />
<br />
Install the bootloader to the drive Arch was installed to (do '''not''' append a partition number, or {{ic|/dev/sda''X''}}):<br />
<br />
# grub-install --target=i386-pc --recheck ''/dev/sda''<br />
<br />
Automatically generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|A sample {{ic|/boot/grub/grub.cfg}} is included with the {{Pkg|grub}} package, and subsequent {{ic|grub-*}} commands may not over-write it. Ensure your intended changes are in {{ic|grub.cfg}}, rather than in {{ic|grub.cfg.new}} or similar file.}}<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
==== For UEFI motherboards ====<br />
<br />
Here, installation with ''gummiboot'' is demonstrated. First install {{Pkg|dosfstools}} to manipulate the EFI System Partition post-installation, and {{Pkg|efibootmgr}} to create a UEFI boot entry (used by bootmanager installation scripts):<br />
<br />
# pacman -S dosfstools efibootmgr<br />
<br />
{{Note|<br />
* For UEFI boot, the drive needs to be GPT-partitioned and an [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] (512 MiB or larger, gdisk type {{ic|EF00}}, formatted with FAT32) must be present. In the following examples, this partition is assumed to be mounted at {{ic|/boot}}. If you have followed this guide from the beginning, you have already done all of these.<br />
* It is strongly recommended to have the EFI System Partition mounted at {{ic|/boot}} as this is required to automatically update Gummiboot.<br />
}}<br />
<br />
Install the {{Pkg|gummiboot}} package and run the automated installation script, replacing {{ic|'''$esp'''}} with the location of your EFI System Partiton, usually {{ic|/boot}}:<br />
<br />
# pacman -S gummiboot<br />
# gummiboot --path='''$esp''' install<br />
<br />
Gummiboot will automatically be detected by firmware that requires that the bootable {{ic|bootx64.efi}} stub be placed in {{ic|'''$esp'''/EFI/boot}}, and will in turn automatically detect the presence of any other installed operating systems using ''.efi'' stubs. However, it will still be necessary to manually create a configuration file for Gummiboot.<br />
<br />
First, create {{ic|'''$esp'''/loader/entries/arch.conf}} and add the following, replacing {{ic|/dev/sdaX}} with your '''root''' partition (most likely {{ic|/dev/sda2}} if {{ic|/dev/sda1}} is the ESP):<br />
<br />
{{hc|# nano '''$esp'''/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root='''/dev/sdaX''' rw<br />
}}<br />
<br />
Second, create {{ic|'''$esp'''/loader/loader.conf}} and add the following, replacing the timeout value (in seconds) with your own choice:<br />
{{hc|# nano '''$esp'''/loader/loader.conf|2=<br />
default arch<br />
timeout 5<br />
}}<br />
<br />
See [[gummiboot]] for more information.<br />
<br />
== Unmount the partitions and reboot ==<br />
<br />
Exit from the chroot environment:<br />
<br />
# exit<br />
<br />
Reboot the computer. Partitions will be unmounted automatically by ''systemd'' on shutdown. You may however unmount with {{ic|umount -R /mnt}} as a safety measure (if the partition is "busy", you can find the cause with [[fuser]]).<br />
<br />
# reboot<br />
<br />
Remove the installation media, or you may boot back into it. You can log into your new installation as ''root'', using the password you specified with ''passwd''.<br />
<br />
== Post-installation ==<br />
<br />
Your new Arch Linux base system is now a functional GNU/Linux environment ready to be built into whatever you wish or require for your purposes. You are now ''strongly'' advised to read the [[General recommendations]] article, especially the first two sections. Its other sections provide links to post-installation tutorials like setting up a graphical user interface, sound or a touchpad.<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Bwidhttps://wiki.archlinux.org/index.php?title=User:Bwid&diff=373863User:Bwid2015-05-16T04:36:58Z<p>Bwid: </p>
<hr />
<div>== todo ==<br />
* Look at how / where in the wiki is the explanation to write X modelines. Maybe improve it. If the method is different from the one i used in bumblebee article, look at resulting modeline and if its different from the one generated by amlc test if still works. Change bumblebee article to just reference the "generate modeline" section elsewhere in the wiki. Look into the xorg-conf snipets that are in the 3-head section of bumblebee article, maybe one of them can be done away with without reducing information content<br />
* "MBR partition table" is likely not really correct terminology. Its basically the boot sector . And the first version of old msdos partition table where contained completely in it? Think about using "msdos partition table" or "classic partition table".</div>Bwidhttps://wiki.archlinux.org/index.php?title=User_talk:Bwid&diff=373862User talk:Bwid2015-05-16T04:36:41Z<p>Bwid: Blanked the page</p>
<hr />
<div></div>Bwidhttps://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=336573Beginners' guide2014-09-21T17:09:12Z<p>Bwid: /* Create filesystems */ Someone on irc was trying to mount the bios-boot-part on /boot. Add remark/explanation that those are 2 different things.</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:Beginners' Guide]]<br />
[[bg:Beginners' Guide]]<br />
[[cs:Beginners' Guide]]<br />
[[da:Beginners' Guide]]<br />
[[de:Anleitung für Einsteiger]]<br />
[[el:Beginners' Guide]]<br />
[[es:Beginners' Guide]]<br />
[[fa:راهنمای تازهکارها]]<br />
[[fr:Installation]]<br />
[[he:Beginners' Guide]]<br />
[[hr:Beginners' Guide]]<br />
[[hu:Beginners' Guide]]<br />
[[id:Beginners' Guide]]<br />
[[it:Beginners' Guide]]<br />
[[ja:Beginners' Guide]]<br />
[[ko:Beginners' Guide]]<br />
[[lt:Beginners' Guide]]<br />
[[nl:Beginners' Guide]]<br />
[[pl:Beginners' Guide]]<br />
[[pt:Beginners' Guide]]<br />
[[ro:Ghidul începătorilor]]<br />
[[ru:Beginners' guide]]<br />
[[sk:Beginners' Guide]]<br />
[[sr:Beginners' Guide]]<br />
[[sv:Nybörjarguiden]]<br />
[[tr:Yeni başlayanlar rehberi]]<br />
[[uk:Beginners' Guide]]<br />
[[zh-CN:Beginners' guide]]<br />
[[zh-TW:Beginners' Guide]]<br />
{{Related articles start}}<br />
{{Related|:Category:Accessibility}}<br />
{{Related|Installation guide}}<br />
{{Related|Diskless system}}<br />
{{Related|Install from SSH}}<br />
{{Related|General recommendations}}<br />
{{Related|General troubleshooting}}<br />
{{Related articles end}}<br />
This document will guide you through the process of installing [[Arch Linux]] using the [https://projects.archlinux.org/arch-install-scripts.git/ Arch Install Scripts]. Before installing, you are advised to skim over the [[FAQ]].<br />
<br />
The community-maintained [[Main page|ArchWiki]] is the primary resource that should be consulted if issues arise. The [[IRC channel]] (irc://irc.freenode.net/#archlinux) and the [https://bbs.archlinux.org/ forums] are also excellent resources if an answer cannot be found elsewhere. In accordance with [[the Arch Way]], you are encouraged to type {{ic|man ''command''}} to read the {{ic|man}} page of any command you are unfamiliar with.<br />
<br />
== Preparation ==<br />
<br />
{{Note|If you wish to install from an existing GNU/Linux distribution, please see [[Install from Existing Linux]]. This can be useful particularly if you plan to install Arch via [[VNC]] or [[SSH]] remotely. Users seeking to perform the Arch Linux installation remotely via an [[SSH]] connection should read [[Install from SSH]] for additional tips.}}<br />
<br />
=== System requirements ===<br />
<br />
Arch Linux should run on any [[Wikipedia:P6 (microarchitecture)|i686]] compatible machine with a minimum of 64 MB RAM. A basic installation with all packages from the {{Grp|base}} group should take less than 800 MB of disk space. If you are working with limited space, this can be trimmed down considerably, but you will have to know what you are doing.<br />
<br />
=== Prepare the latest installation medium ===<br />
<br />
The latest release of the installation media can be obtained from the [https://archlinux.org/download/ Download] page. Note that the single ISO image supports both 32 and 64-bit architectures. It is highly recommended to always use the latest ISO image.<br />
<br />
{{Tip|The [https://downloads.archlinux.de/iso/archboot/latest archboot] ISO images can take several steps explained in this guide [[Archboot#Interactive_setup_features|interactively]]. See [[Archboot]] for details.}}<br />
<br />
* Install images are signed and it is highly recommended to verify their signature before use. Dowload the ''.sig'' file from the download page (or one of the mirrors listed there) to the same directory as the ''.iso'' file. On Arch Linux, use {{ic|pacman-key -v ''iso-file''.sig}} as root; in other environments make use, still as root, of gpg2 directly with {{ic|gpg2 --verify ''iso-file''.sig}}. The file integrity checksums md5 and sha1 are also provided {{Note|The gpg2 verification will fail if you have not downloaded the public key corresponding to the RSA key ID. See http://sparewotw.wordpress.com/2012/10/31/how-to-verify-signature-using-sig-file/ for details}}<br />
* Burn the ISO image on a CD or DVD with your preferred software. On Arch, that is covered in [[Optical disc drive#Burning]] <br> {{Note|The quality of optical drives and the discs themselves varies greatly. Generally, using a slow burn speed is recommended for reliable burns. If you are experiencing unexpected behaviour from the disc, try burning at the lowest speed supported by your burner}}<br />
* Or you can write the ISO image to a USB stick. For detailed instructions, see [[USB flash installation media]]<br />
<br />
==== Installing over the network ====<br />
<br />
Instead of writing the boot media to a disc or USB stick, you may alternatively boot the ISO image over the network. This works well when you already have a server set up. Please see the [[PXE]] article for more information, and then continue to [[#Boot the installation medium]].<br />
<br />
==== Install from an existing Linux system ====<br />
<br />
Alternatively, it is possible to install from an already running Linux system. See [[Install from Existing Linux]].<br />
<br />
==== Installing on a virtual machine ====<br />
<br />
Installing on a [[Wikipedia:Virtual machine|virtual machine]] is a good way to become familiar with Arch Linux and its installation procedure without leaving your current operating system and repartitioning the storage drive. It will also let you keep this Beginners' Guide open in your browser throughout the installation. Some users may find it beneficial to have an independent Arch Linux system on a virtual drive, for testing purposes.<br />
<br />
Examples of virtualization software are [[VirtualBox]], [[VMware]], [[QEMU]], [[Xen]], [[Parallels]].<br />
<br />
The exact procedure for preparing a virtual machine depends on the software, but will generally follow these steps:<br />
<br />
# Create the virtual disk image that will host the operating system.<br />
# Properly configure the virtual machine parameters.<br />
# Boot the downloaded ISO image with a virtual CD drive.<br />
# Continue with [[#Boot the installation medium|Boot the installation medium]].<br />
<br />
The following articles may be helpful:<br />
<br />
* [[VirtualBox#Installation steps for Arch Linux guests|Arch Linux as VirtualBox guest]]<br />
* [[Installing Arch Linux from VirtualBox]]<br />
* [[VirtualBox Arch Linux Guest On Physical Drive|Arch Linux as VirtualBox guest on a physical drive]]<br />
* [[Installing Arch Linux in VMware|Arch Linux as VMware guest]]<br />
* [[Moving an existing install into (or out of) a virtual machine]]<br />
<br />
==== Boot the installation medium ====<br />
<br />
Most modern systems allow you to select the boot device during the [[Wikipedia:Power-on self test|POST]] phase, usually by pressing the {{ic|F12}} key while the BIOS splash screen is visible. Select the device which contains the Arch ISO. Alternatively, you may need to change the boot order in your computer's BIOS. <br />
<br />
To do this, press a key (usually {{ic|Delete}}, {{ic|F1}}, {{ic|F2}}, {{ic|F11}} or {{ic|F12}}) during the [[Wikipedia:Power-on self test|POST]] phase. This will take you into the BIOS settings screen where you can set the order in which the system searches for devices to boot from. Set the device which contains the Arch ISO as the first device from which boot is attempted. Select "Save & Exit" (or your BIOS's equivalent) and the computer should then complete its normal boot process.<br />
<br />
When the Arch menu appears, select "Boot Arch Linux" and press {{ic|Enter}} to enter the live environment where you will run the actual installation (if booting from a UEFI boot disk, the option may look more like "Arch Linux archiso x86_64 UEFI").<br />
<br />
===== Testing if you are booted into UEFI mode =====<br />
<br />
In case you have a [[Unified Extensible Firmware Interface|UEFI]] motherboard and UEFI Boot mode is enabled (and is preferred over BIOS/Legacy mode), the CD/USB will automatically launch Arch Linux via [[Gummiboot]] and you will get the following menu (white letters on black background), with the first item highlighted:<br />
{{bc|<br />
Arch Linux archiso x86_64 UEFI USB<br />
UEFI Shell x86_64 v1<br />
UEFI Shell x86_64 v2<br />
EFI Default Loader}}<br />
<br />
If you do not remember which menu you had at boot time, or if you want to make sure you booted into UEFI mode, run:<br />
<br />
# efivar -l<br />
<br />
If ''efivar'' lists the UEFI variables properly, then you have booted in UEFI mode. If not check whether all the requirements listed in [[Unified Extensible Firmware Interface#Requirements for UEFI Variables support to work properly|Unified Extensible Firmware Interface]] are met.<br />
<br />
==== Troubleshooting boot problems ====<br />
<br />
* If you are using an Intel video chipset and the screen goes blank during the boot process, the problem is likely an issue with [[Kernel mode setting]]. A possible workaround may be achieved by rebooting and pressing {{ic|Tab}} over the entry that you are trying to boot (i686 or x86_64). At the end of the string type {{ic|nomodeset}} and press {{ic|Enter}}. Alternatively, try {{ic|1=video=SVIDEO-1:d}} which, if it works, will not disable kernel mode setting. You can also try {{ic|1=i915.modeset=0}}. See the [[Intel]] article for more information.<br />
* If the screen does ''not'' go blank and the boot process gets stuck while trying to load the kernel, press {{ic|Tab}} while hovering over the menu entry, type {{ic|1=acpi=off}} at the end of the string and press {{ic|Enter}}.<br />
<br />
== Installation ==<br />
<br />
You are now presented with a shell prompt, automatically logged in as root. Your shell is [[Zsh]]; this will provide you advanced Tab completion, and other features as part of the [http://grml.org/zsh/ grml config].<br />
For editing text files, the console editor ''nano'' is suggested. If you are not familiar with it, see [[nano#nano usage]].<br />
If you have (or plan on having) a dual boot setup with Windows, see [[Windows and Arch Dual Boot]].<br />
<br />
=== Change the language ===<br />
<br />
{{Tip|These are optional for the majority of users. Useful only if you plan on writing in your own language in any of the configuration files, if you use diacritical marks in the Wi-Fi password, or if you would like to receive system messages (e.g. possible errors) in your own language. Changes here ''only'' affect the installation process.}}<br />
<br />
By default, the keyboard layout is set to {{ic|us}}. If you have a non-[[Wikipedia:File:KB United States-NoAltGr.svg|US]] keyboard layout, run:<br />
<br />
# loadkeys ''layout''<br />
<br />
...where ''layout'' can be {{ic|fr}}, {{ic|uk}}, {{ic|dvorak}}, {{ic|be-latin1}}, etc. See this [[Wikipedia:ISO 3166-1 alpha-2#Officially assigned code elements|wikipedia article]] for a 2-letter country code list. Use the command {{ic|localectl list-keymaps}} to list all available keymaps.<br />
<br />
If some glyphs of your language's alphabet (e.g. accented and non Latin letters) show up as white squares or as other symbols, you may want to change the console font with one from {{ic|/usr/share/kbd/consolefonts/}}. For example:<br />
<br />
# setfont lat9w-16<br />
<br />
You can run the {{ic|showconsolefont}} command to display the full contents of the loaded font. Note that the font name is case-sensitive, so type it ''exactly'' as you see it. See [[Fonts#Console fonts]] for more information.<br />
<br />
By default, the language is set to English (US). If you would like to change the language for the install process ''(German, in this example)'', remove the {{ic|#}} in front of the [[locale]] you want from {{ic|/etc/locale.gen}}, along with English (US). Please choose the {{ic|UTF-8}} entries:<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
en_US.UTF-8 UTF-8<br />
de_DE.UTF-8 UTF-8<br />
}}<br />
<br />
# locale-gen<br />
# export LANG=de_DE.UTF-8<br />
<br />
=== Establish an internet connection ===<br />
<br />
{{Warning|As of [http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id&#61;dee4c244254bb49d1ffa8bd7171ae9cce596d2d0 v197], udev no longer assigns network interface names according to the ''wlanX'' and ''ethX'' naming scheme. If you are coming from a different distribution or are reinstalling Arch and not aware of the new interface naming style, please do not assume that your wireless interface is named ''wlan0'', or that your wired interface is named ''eth0''. You can use the command {{ic|ip link}} to discover the names of your interfaces.}}<br />
<br />
{{Note|Since the ISO released on 2014.04 (but maybe even on previous ones) there seems to be a problem in getting an IP address with DHCP if you are using the family of routers "FritzBox!". At this time models 7390[http://unix.stackexchange.com/questions/126526/archlinux-2014-04-64bit-and-connectivity-problem-during-instalation] and 7112[https://unix.stackexchange.com/questions/126694/enabling-wired-internet-connection-with-dhcp-during-arch-linux-installation/126709] seem to have this issue, but other models may be affected. The issue seems to be between the [[dhcpcd]] client and the FritzBox! routers and the way they assign IP addresses. The solution to the problem seems to be as follows: in your FritzBox! settings, manually delete the entry related to the IP address that identifies your machine. Also, disable the option "Assign always the same IP address to this machine". Now restart the DHCP process or simply reboot your computer and you should get an IP address as usual. If it does not work, try also to reboot your FritzBox!. Once your computer gets the IP address, you can re-enable the previously disabled option. }}<br />
<br />
The {{ic|dhcpcd}} network daemon starts automatically during boot and it will attempt to start a wired connection. Try to ping a server to see if a connection was established. For example, Google's webservers:<br />
<br />
{{hc|# ping -c 3 www.google.com|2=<br />
PING www.l.google.com (74.125.132.105) 56(84) bytes of data.<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=1 ttl=50 time=17.0 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=2 ttl=50 time=18.2 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=3 ttl=50 time=16.6 ms<br />
<br />
--- www.l.google.com ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2003ms<br />
rtt min/avg/max/mdev = 16.660/17.320/18.254/0.678 ms<br />
}}<br />
<br />
If you get a {{ic|ping: unknown host}} error, first check if there is an issue with your cable or wireless signal strength. If not, you will need to set up the network manually, as explained below. Once a connection is established move on to [[#Prepare the storage drive]].<br />
<br />
==== Wired ====<br />
<br />
Follow this procedure if you need to set up a wired connection via a static IP address.<br />
<br />
First, disable the dhcpcd service which was started automatically at boot:<br />
<br />
# systemctl stop dhcpcd.service<br />
<br />
Identify the name of your Ethernet interface.<br />
<br />
{{hc|# ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp2s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000<br />
link/ether 00:11:25:31:69:20 brd ff:ff:ff:ff:ff:ff<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000<br />
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
In this example, the Ethernet interface is {{ic|enp2s0f0}}. If you are unsure, your Ethernet interface is likely to start with the letter "e", and unlikely to be "lo" or start with the letter "w".<br />
<br />
You also need to know these settings:<br />
<br />
* Static IP address.<br />
* Subnet mask.<br />
* Gateway's IP address.<br />
* Name servers' (DNS) IP addresses.<br />
* Domain name (unless you are on a local LAN, in which case you can make it up).<br />
<br />
Activate the connected Ethernet interface (e.g. {{ic|enp2s0f0}}):<br />
<br />
# ip link set enp2s0f0 up<br />
<br />
Add the address:<br />
<br />
# ip addr add ''ip_address''/''mask_bits'' dev ''interface_name''<br />
<br />
For example:<br />
<br />
# ip addr add 192.168.1.2/24 dev enp2s0f0<br />
<br />
For more options, run {{ic|man ip}}.<br />
<br />
Add your gateway like this, substituting your own gateway's IP address:<br />
<br />
# ip route add default via ''ip_address''<br />
<br />
For example:<br />
<br />
# ip route add default via 192.168.1.1<br />
<br />
Edit {{ic|resolv.conf}}, substituting your name servers' IP addresses and your local domain name:<br />
<br />
{{hc|# nano /etc/resolv.conf|<br />
nameserver 61.23.173.5<br />
nameserver 61.95.849.8<br />
search example.com<br />
}}<br />
<br />
{{Note|Currently, you may include a maximum of three {{ic|nameserver}} lines. In order to overcome this limitation, you can use a locally caching nameserver like [[dnsmasq]].}}<br />
<br />
You should now have a working network connection. If you do not, check the detailed [[Network configuration]] page.<br />
<br />
==== Wireless ====<br />
<br />
Follow this procedure if you need wireless connectivity (Wi-Fi) during the installation process.<br />
<br />
First, identify the name of your wireless interface:<br />
<br />
{{hc|# iw dev|2=<br />
phy#0<br />
Interface wlp3s0<br />
ifindex 3<br />
wdev 0x1<br />
addr 00:11:22:33:44:55<br />
type managed<br />
}}<br />
<br />
In this example, {{ic|wlp3s0}} is the available wireless interface. If you are unsure, your wireless interface is likely to start with the letter "w", and unlikely to be "lo" or start with the letter "e". <br />
<br />
{{Note|If you do not see output similar to this, then your wireless driver has not been loaded. If this is the case, you must load the driver yourself. Please see [[Wireless network configuration]] for more detailed information.}}<br />
<br />
Now use [[netctl]]'s {{ic|wifi-menu}} to connect to a network:<br />
<br />
# wifi-menu wlp3s0<br />
<br />
You should now have a working network connection. If you do not, try [[#Without wifi-menu]] or check the detailed [[Wireless network configuration]] page.<br />
<br />
===== Without wifi-menu =====<br />
<br />
Bring the interface up with:<br />
<br />
# ip link set wlp3s0 up<br />
<br />
To verify that the interface is up, inspect the output of the following command:<br />
<br />
{{hc|# ip link show wlp3s0|<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000<br />
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
The {{ic|UP}} in {{ic|<BROADCAST,MULTICAST,UP,LOWER_UP>}} is what indicates the interface is up, not the later {{ic|state DOWN}}.<br />
<br />
Most wireless chipsets require firmware in addition to a corresponding driver. The kernel tries to identify and load both automatically. If you get output like {{ic|SIOCSIFFLAGS: No such file or directory}}, this means you will need to manually load the firmware. If unsure, invoke {{ic|dmesg}} to query the kernel log for a firmware request from the wireless chipset. For example, if you have an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
<br />
{{hc|<nowiki># dmesg | grep firmware</nowiki>|<br />
firmware: requesting iwlwifi-5000-1.ucode<br />
}}<br />
<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
{{Warning|Wireless chipset firmware packages (for cards which require them) are pre-installed under {{ic|/usr/lib/firmware}} in the live environment (on CD/USB stick) '''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!''' Package installation is covered later in this guide. Ensure installation of both your wireless module and firmware before rebooting! See [[Wireless network configuration]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset.}}<br />
<br />
Next, scan for available networks using {{ic|iw dev wlp3s0 scan <nowiki>|</nowiki> grep SSID}}, then connect to a network with:<br />
<br />
# wpa_supplicant -B -i wlp3s0 -c <(wpa_passphrase "''ssid''" "''psk''")<br />
<br />
You need to replace ''ssid'' with the name of your network (e.g. "Linksys etc...") and ''psk'' with your wireless password, '''leaving the quotes around the network name and password'''.<br />
<br />
Finally, you have to give your interface an IP address. This can be set manually or using dhcp:<br />
<br />
# dhcpcd wlp3s0<br />
<br />
If that does not work, issue the following commands:<br />
<br />
# echo 'ctrl_interface=DIR=/run/wpa_supplicant' > /etc/wpa_supplicant.conf<br />
# wpa_passphrase ''ssid'' ''passphrase'' >> /etc/wpa_supplicant.conf<br />
# ip link set ''interface'' up<br />
# wpa_supplicant -B -D nl80211 -c /etc/wpa_supplicant.conf -i ''interface''<br />
# dhcpcd -A ''interface''<br />
<br />
Setting the interface up at step 3 may not be needed, but does no harm in any case.<br />
<br />
If ''wpa_supplicant'' complains about an unsupported driver at step 4, just leave out the {{ic|-D nl80211}} parameter:<br />
<br />
# wpa_supplicant -B -c /etc/wpa_supplicant.conf -i ''interface''<br />
<br />
==== Analog modem, ISDN, or PPPoE DSL ====<br />
<br />
For xDSL, dial-up, and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
==== Behind a proxy server ====<br />
<br />
If you are behind a proxy server, you will need to export the {{ic|http_proxy}} and {{ic|ftp_proxy}} environment variables. See [[Proxy settings]] for more information.<br />
<br />
=== Prepare the storage drive ===<br />
<br />
{{Warning|Partitioning can destroy data. You are '''strongly''' cautioned and advised to backup any critical data before proceeding.}}<br />
{{Note|If you are installing to a USB flash key, see [[Installing Arch Linux on a USB key]].}}<br />
{{Tip|If you want to create any stacked block devices for [[LVM]], [[disk encryption]] or [[RAID]], do it now.}}<br />
<br />
==== Choose a partition table type ====<br />
<br />
{{Note|If Arch and Windows are dual-booting from same disk, then Arch '''should''' follow the same firmware boot mode and partitioning combination used by the installed Windows in the disk. Otherwise Windows will fail to boot. See [[Windows and Arch Dual Boot#Important information]] for details.}}<br />
<br />
You have to choose between [[GUID Partition Table]] (GPT) and [[Master Boot Record]] (MBR), see also [[Partitioning#Choosing between GPT and MBR]].<br />
<br />
* It is recommended to always use GPT for UEFI boot, as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* Some BIOS systems may have issues with GPT. See http://mjg59.dreamwidth.org/8035.html and http://rodsbooks.com/gdisk/bios.html for more info and possible workarounds.<br />
<br />
==== Partitioning tool ====<br />
<br />
Absolute beginners are encouraged to use a graphical partitioning tool. [[GParted]] is a good example, and is [http://gparted.sourceforge.net/livecd.php provided as a live CD]. A drive should first be [[partitioning|partitioned]] and afterwards the partitions should be formatted with a [[File systems|file system]].<br />
<br />
While ''gparted'' may be easier to use, if you just want to create a few partitions on a new disk you can get the job done quickly by just using one of the [[Partitioning#Partitioning tools|fdisk variants]] which are included on the install medium. In the next section short usage instructions for both [[Partitioning#Gdisk usage summary|gdisk]] and [[Partitioning#Fdisk usage summary|fdisk]] follow.<br />
<br />
==== Erase partition table ====<br />
<br />
If you want to start from scratch, and do not intend to keep existing partitions, erase the partition table with the following command. This simplifies creating new partitions and avoids problems with converting disks from MBR to GPT and vice versa.<br />
<br />
# sgdisk --zap-all /dev/sda<br />
<br />
==== Partition scheme ====<br />
<br />
You can decide into how many partitions the disk should be split, and for which directory each partition should be used in the system. The mapping from partitions to directories (frequently called 'mount points') is the [[Partitioning#Partition scheme|Partition scheme]]. The simplest, and not a bad choice, is to make just one huge {{ic|/}} partition. Another popular choice is to have a {{ic|/}} and a {{ic|/home}} partition.<br />
<br />
'''Additional required partitions:'''<br />
* If you have a [[Unified Extensible Firmware Interface|UEFI]] motherboard, you will need to create an extra [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]].<br />
* If you have a BIOS motherboard (or plan on booting in BIOS compatibility mode) and you want to setup GRUB on a GPT-partitioned drive, you will need to create an extra [[GRUB#GUID Partition Table (GPT) specific instructions|BIOS Boot Partition]] of size 1 or 2 MiB and {{ic|EF02}} type code. Syslinux does not need one.<br />
* If you have a requirement for a [[Disk encryption]] of the system itself, this must be reflected in your partition scheme. It is unproblematic to add encrypted folders, containers or home directories after the system is installed.<br />
<br />
See [[Swap]] for details if you wish to set up a swap partition or swap file. A swap file is easier to resize than a partition and can be created at any point after installation, but cannot be used with a Btrfs filesystem.<br />
<br />
If you have already created your partitions, proceed to [[#Create filesystems]]. Otherwise, see the following example.<br />
<br />
==== Example ====<br />
<br />
The Arch Linux install media includes the following partitioning tools: {{ic|fdisk}}, {{ic|gdisk}}, {{ic|cfdisk}}, {{ic|cgdisk}} and {{ic|parted}}.<br />
<br />
{{Tip|Use the {{ic|lsblk}} command to list the hard disks attached to your system, along with the sizes of their existing partitions. This will help you to be confident you are partitioning the right disk. {{ic|lsblk -f}} will show additional information about Labels, UUIDs and filesystem types.}}<br />
<br />
The example system will contain a 15 GB root partition, and a [[Partitioning#/home|home]] partition for the remaining space. Choose either MBR or GPT, as described above. Do not choose both!<br />
<br />
It should be emphasized that partitioning is a personal choice and that this example is only for illustrative purposes. See [[Partitioning]].<br />
<br />
===== Using cgdisk to create GPT partitions =====<br />
<br />
Launch ''cgdisk'' with:<br />
<br />
# cgdisk /dev/sda<br />
<br />
{{Tip|If cgdisk cannot change your disk to GPT, {{pkg|parted}} can.}}<br />
<br />
'''Root:'''<br />
* Choose ''New'' (or press {{ic|N}}) – {{ic|Enter}} for the first sector (2048) – type in {{ic|15G}} – {{ic|Enter}} for the default hex code (8300) – {{ic|Enter}} for a blank partition name.<br />
<br />
'''Home:'''<br />
* Press the down arrow a couple of times to move to the larger free space area.<br />
* Choose ''New'' (or press {{ic|N}}) – {{ic|Enter}} for the first sector – {{ic|Enter}} to use the rest of the drive (or you could type in the desired size; for example {{ic|30G}}) – {{ic|Enter}} for the default hex code (8300) – {{ic|Enter}} for a blank partition name.<br />
<br />
Here is what it should look like:<br />
<br />
Part. # Size Partition Type Partition Name<br />
----------------------------------------------------------------<br />
1007.0 KiB free space<br />
1 15.0 GiB Linux filesystem<br />
2 123.45 GiB Linux filesystem<br />
<br />
Double check and make sure that you are happy with the partition sizes as well as the partition table layout before continuing.<br />
<br />
If you would like to start over, you can simply select ''Quit'' (or press {{ic|Q}}) to exit without saving changes and then restart ''cgdisk''.<br />
<br />
If you are satisfied, choose ''Write'' (or press {{ic|Shift+W}}) to finalize and to write the partition table to the drive. Type {{ic|yes}} and choose ''Quit'' (or press {{ic|Q}}) to exit without making any more changes.<br />
<br />
===== Using fdisk to create MBR partitions =====<br />
<br />
{{Note|There is also ''cfdisk'', which is similar in UI to ''cgdisk'', but it currently does not automatically align the first partition properly. That is why the classic ''fdisk'' tool is used here.}}<br />
<br />
Launch ''fdisk'' with:<br />
<br />
# fdisk /dev/sda<br />
<br />
Create the partition table:<br />
<br />
* {{ic|Command (m for help):}} type {{ic|o}} and press {{ic|Enter}}<br />
<br />
Then create the first partition:<br />
<br />
# {{ic|Command (m for help):}} type {{ic|n}} and press {{ic|Enter}}<br />
# Partition type: {{ic|Select (default p):}} press {{ic|Enter}}<br />
# {{ic|Partition number (1-4, default 1):}} press {{ic|Enter}}<br />
# {{ic|First sector (2048-209715199, default 2048):}} press {{ic|Enter}}<br />
# {{ic|Last sector, +sectors or +size{K,M,G,T,P} (2048-209715199....., default 209715199):}} type {{ic|+15G}} and press {{ic|Enter}}<br />
<br />
Then create a second partition:<br />
<br />
# {{ic|Command (m for help):}} type {{ic|n}} and press {{ic|Enter}}<br />
# Partition type: {{ic|Select (default p):}} press {{ic|Enter}}<br />
# {{ic|Partition number (1-4, default 2):}} press {{ic|Enter}}<br />
# {{ic|First sector (31459328-209715199, default 31459328):}} press {{ic|Enter}}<br />
# {{ic|Last sector, +sectors or +size{K,M,G,T,P} (31459328-209715199....., default 209715199):}} press {{ic|Enter}}<br />
<br />
Now preview the new partition table:<br />
<br />
* {{ic|Command (m for help):}} type {{ic|p}} and press {{ic|Enter}}<br />
<br />
{{bc|<br />
Disk /dev/sda: 107.4 GB, 107374182400 bytes, 209715200 sectors<br />
Units &#61; sectors of 1 * 512 &#61; 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x5698d902<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sda1 2048 31459327 15728640 83 Linux<br />
/dev/sda2 31459328 209715199 89127936 83 Linux<br />
}}<br />
<br />
Then write the changes to disk:<br />
<br />
* {{ic|Command (m for help):}} type {{ic|w}} and press {{ic|Enter}}<br />
<br />
If everything went well fdisk will now quit with the following message:<br />
<br />
{{bc|<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks. <br />
}}<br />
<br />
In case this does not work because ''fdisk'' encountered an error, you can use the {{ic|q}} command to exit.<br />
<br />
==== Create filesystems ====<br />
<br />
Simply partitioning is not enough; the partitions also need a [[File systems|filesystem]]. To format the partitions with an ext4 filesystem:<br />
<br />
{{Warning|Double check and triple check that it is actually {{ic|/dev/sda1}} and {{ic|/dev/sda2}} that you want to format. You can use {{ic|lsblk}} to help with this.}}<br />
<br />
# mkfs.ext4 /dev/sda1<br />
# mkfs.ext4 /dev/sda2<br />
<br />
If you have made a partition dedicated to swap (code 82), do not forget to format and activate it with:<br />
<br />
# mkswap /dev/sda''X''<br />
# swapon /dev/sda''X''<br />
<br />
For UEFI, you should format the EFI System Partition (for example /dev/sd''XY'') with:<br />
<br />
# mkfs.fat -F32 /dev/sd''XY''<br />
<br />
If you plan to use [[GRUB]] on a BIOS system using a [[GPT|GUID Partition Table]], please note that the [[GRUB#GUID Partition Table (GPT) specific instructions|BIOS Boot Partition]] has nothing to do with the {{ic|/boot}} mountpoint. It will be used by GRUB directly. Do not create a filesystem on it, and do not mount it anywhere in the next step.<br />
<br />
=== Mount the partitions ===<br />
<br />
Each partition is identified with a number suffix. For example, {{ic|sda1}} specifies the first partition of the first drive, while {{ic|sda}} designates the entire drive.<br />
<br />
To display the current partition layout:<br />
<br />
# lsblk -f<br />
<br />
{{Note|Do not mount more than one partition to the same directory. And pay attention, because the mounting order is important.}}<br />
<br />
First, mount the root partition on {{ic|/mnt}}. Following the example above (yours may be different), it would be:<br />
<br />
# mount /dev/sda1 /mnt<br />
<br />
Then mount the home partition and any other separate partition ({{ic|/boot}}, {{ic|/var}}, etc), if you have any:<br />
<br />
# mkdir /mnt/home<br />
# mount /dev/sda2 /mnt/home<br />
<br />
In case you have a UEFI motherboard, mount the EFI System Partition to {{ic|/boot}}. Whilst other mountpoints are viable, using {{ic|/boot}} is recommended as explained in the [[EFISTUB]] article.<br />
<br />
# mkdir /mnt/boot<br />
# mount /dev/sd''XY'' /mnt/boot<br />
<br />
=== Select a mirror ===<br />
<br />
You may want to edit the {{ic|mirrorlist}} file and place your preferred mirror first. A copy of this file will be installed on your new system by {{ic|pacstrap}} as well, so it is worth getting it right.<br />
<br />
{{hc|# nano /etc/pacman.d/mirrorlist|<br />
##<br />
## Arch Linux repository mirrorlist<br />
## Sorted by mirror score from mirror status page<br />
## Generated on 2012-MM-DD<br />
##<br />
<br />
<nowiki>Server = http://mirror.example.xyz/archlinux/$repo/os/$arch</nowiki><br />
...}}<br />
<br />
If you want, you can make it the ''only'' mirror available by deleting all other lines, but it is usually a good idea to have a few more, in case the first one goes offline.<br />
<br />
{{Tip|<br />
* Use the [https://www.archlinux.org/mirrorlist/ Mirrorlist Generator] to get an updated list for your country. HTTP mirrors are faster than FTP, because of something called [[Wikipedia:Keepalive|keepalive]]. With FTP, ''pacman'' has to send out a signal each time it downloads a package, resulting in a brief pause. For other ways to generate a mirror list, see [[Mirrors#Sorting mirrors|Sorting mirrors]] and [[Reflector]].<br />
* [https://archlinux.org/mirrors/status/ Arch Linux MirrorStatus] reports various aspects about the mirrors such as network problems with mirrors, data collection problems, the last time mirrors have been synced, etc.<br />
}}<br />
<br />
{{Note|<br />
* Whenever in the future you change your mirrorlist, refresh all package lists with {{ic|pacman -Syy}}, to ensure that the package lists are updated consistently. See [[Mirrors]] for more information.<br />
* If you are using an older installation medium, your mirrorlist might be outdated, which might lead to problems when updating Arch Linux (see {{Bug|22510}}). Therefore it is advised to obtain the latest mirror information as described above.<br />
* Some issues have been reported in the [https://bbs.archlinux.org/ Arch Linux forums] regarding network problems that prevent ''pacman'' from updating/synchronizing repositories (see [https://bbs.archlinux.org/viewtopic.php?id&#61;68944] and [https://bbs.archlinux.org/viewtopic.php?id&#61;65728]). When installing Arch Linux natively, these issues have been resolved by replacing the default ''pacman'' file downloader with an alternative (see [[Improve pacman performance]] for more details). When installing Arch Linux as a guest OS in [[VirtualBox]], this issue has also been addressed by using "Host interface" instead of "NAT" in the machine properties.<br />
}}<br />
<br />
=== Install the base system ===<br />
<br />
The base system is installed using the ''pacstrap'' script. The {{ic|-i}} switch can be omitted if you wish to install every package from the {{Grp|base}} group without prompting. You may also want to include {{Grp|base-devel}}, as you will need these packages should you want to build packages from the [[AUR]] or using the [[ABS]]:<br />
<br />
# pacstrap -i /mnt base base-devel<br />
<br />
{{Note|<br />
* If ''pacstrap'' hangs with {{ic|error: failed retrieving file 'core.db' from mirror... : Connection time-out}}, yet your mirrors are configured correctly, try setting a different [[Resolv.conf|name server]].<br />
* If in the middle of the installation of base packages you get a request to import a PGP key, agree to download the key to proceed. This is likely to happen if the Arch ISO you are using is out of date.<br />
* If ''pacman'' fails to verify your packages, stop the process with {{ic|Ctrl+C}} and check the system time with {{ic|cal}}. If the system date is invalid (e.g. it shows the year 2010), signing keys will be considered expired (or invalid), signature checks on packages will fail and installation will be interrupted. Make sure to correct the system time, using the command {{ic|ntpd -qg}}, and retry running the ''pacstrap'' command. Refer to [[Time]] page for more information on correcting system time.<br />
* If ''pacman'' complains that {{ic|error: failed to commit transaction (invalid or corrupted package)}}, run the following command:<br />
# pacman-key --init && pacman-key --populate archlinux<br />
}}<br />
<br />
This will give you a basic Arch system. Other packages can be installed later using [[pacman]].<br />
<br />
=== Generate an fstab ===<br />
<br />
Generate an [[fstab]] file with the following command. UUIDs will be used because they have certain advantages (see [[fstab#Identifying filesystems]]). If you would prefer to use labels instead, replace the {{ic|-U}} option with {{ic|-L}}:<br />
<br />
# genfstab -U -p /mnt >> /mnt/etc/fstab<br />
# nano /mnt/etc/fstab<br />
<br />
{{Warning|The {{ic|fstab}} file should always be checked after generating it. If you encounter errors running ''genfstab'' or later in the install process, do '''not''' run ''genfstab'' again; just edit the {{ic|fstab}} file.}}<br />
<br />
A few considerations:<br />
<br />
* The last field determines the order in which partitions are checked at start up: use {{ic|1}} for the (non-Btrfs) root partition, which should be checked first; {{ic|2}} for all other partitions you want checked at start up; and {{ic|0}} means 'do not check' (see [[fstab#Field definitions]]).<br />
* All [[Btrfs]] partitions should have {{ic|0}} for this field. Normally, you will also want your ''swap'' partition to have {{ic|0}}.<br />
<br />
=== Chroot and configure the base system ===<br />
<br />
Next, [[Change Root|chroot]] into your newly installed system:<br />
<br />
# arch-chroot /mnt /bin/bash<br />
<br />
{{Note|Leave out {{ic|/bin/bash}} to chroot into the sh shell.}}<br />
<br />
At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system. These can either be created if they do not exist, or edited if you wish to change the defaults.<br />
<br />
Closely following and understanding these steps is of key importance to ensure a properly configured system.<br />
<br />
==== Locale ====<br />
<br />
Locales are used by {{Pkg|glibc}} and other locale-aware programs or libraries for rendering text, correctly displaying regional monetary values, time and date formats, alphabetic idiosyncrasies, and other locale-specific standards. There are two files that need editing: {{ic|locale.gen}} and {{ic|locale.conf}}.<br />
<br />
The {{ic|locale.gen}} file has everything commented out by default. To uncomment a line remove the {{ic|#}} in the front. Using {{ic|UTF-8}} is highly recommended over {{ic|ISO-8859}}:<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
...<br />
#en_SG ISO-8859-1<br />
en_US.UTF-8 UTF-8<br />
#en_US ISO-8859-1<br />
...<br />
}}<br />
<br />
Generate the locale(s) specified in {{ic|/etc/locale.gen}}:<br />
<br />
# locale-gen<br />
<br />
{{Note|This will also run with every update of {{Pkg|glibc}}.}}<br />
<br />
Create the {{ic|/etc/locale.conf}} file substituting your chosen locale:<br />
<br />
# echo LANG=en_US.UTF-8 > /etc/locale.conf<br />
<br />
{{Note|<br />
* The locale specified in the {{ic|LANG}} variable must be uncommented in {{ic|/etc/locale.gen}}.<br />
* The {{ic|locale.conf}} file does not exist by default. Setting only {{ic|LANG}} should be enough as it will act as the default value for all other variables.<br />
}}<br />
<br />
Export substituting your chosen locale:<br />
<br />
# export LANG=en_US.UTF-8<br />
<br />
{{Tip|To use other locales for other {{ic|LC_*}} variables, run {{ic|locale}} to see the available options and add them to {{ic|locale.conf}}. It is not recommended to set the {{ic|LC_ALL}} variable. See [[Locale#Setting the locale system-wide]] for details.}}<br />
<br />
==== Console font and keymap ====<br />
<br />
If you changed the default console keymap and font in [[#Change the language]], you will have to edit {{ic|/etc/vconsole.conf}} ''accordingly'' (create it if it does not exist) to make those changes persist in the installed system, for example:<br />
<br />
{{hc|# nano /etc/vconsole.conf|2=<br />
KEYMAP=de-latin1<br />
FONT=lat9w-16<br />
}}<br />
<br />
{{Warning|If you set {{ic|KEYMAP}} to a different value than the one you initially set with ''loadkeys'', and then you [[#Set the root password]], you may have problems logging into the new system after rebooting, because some keys may be mapped differently between the two layouts.}}<br />
<br />
Note that these settings are only valid for your virtual consoles, not in [[Xorg]]. See [[Fonts#Console fonts]] for more information.<br />
<br />
==== Time zone ====<br />
<br />
Available time zones and subzones can be found in the {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}} directories.<br />
<br />
To view the available zones, check the directory {{ic|/usr/share/zoneinfo/}}:<br />
<br />
# ls /usr/share/zoneinfo/<br />
<br />
Similarly, you can check the contents of directories belonging to a subzone:<br />
<br />
# ls /usr/share/zoneinfo/Europe<br />
<br />
Create a symbolic link {{ic|/etc/localtime}} to your subzone file {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}} using this command:<br />
<br />
# ln -s /usr/share/zoneinfo/''Zone''/''SubZone'' /etc/localtime<br />
<br />
'''Example:'''<br />
<br />
# ln -s /usr/share/zoneinfo/Europe/Minsk /etc/localtime<br />
<br />
{{Note|If you get {{ic|ln: failed to create symbolic link '/etc/localtime': File exists}}, check the existing file with {{ic|ls -l /etc/localtime}} and add the {{ic|-f}} option to the ''ln'' command to overwrite it.}}<br />
<br />
==== Hardware clock ====<br />
<br />
Set the hardware clock mode uniformly between your operating systems. Otherwise, they may overwrite the hardware clock and cause time shifts.<br />
<br />
You can generate {{ic|/etc/adjtime}} automatically by using one of the following commands:<br />
<br />
* '''UTC''' (recommended): {{Note|Using [[Wikipedia:Coordinated Universal Time|UTC]] for the hardware clock does not mean that software will display time in UTC.}} {{bc|# hwclock --systohc --utc}}<br />
* '''localtime''' (discouraged; used by default in Windows): {{Warning|Using ''localtime'' may lead to several known and unfixable bugs. However, there are no plans to drop support for ''localtime''.}} {{bc|# hwclock --systohc --localtime}}<br />
<br />
==== Kernel modules ====<br />
<br />
{{Tip|This is just an example, you do not need to set it. All needed modules are automatically loaded by udev, so you will rarely need to add something here. Only add modules that you know are missing.}}<br />
<br />
For kernel modules to load during boot, place a {{ic|*.conf}} file in {{ic|/etc/modules-load.d/}}, with a name based on the program that uses them:<br />
<br />
{{hc|# nano /etc/modules-load.d/virtio-net.conf|<br />
# Load 'virtio-net.ko' at boot.<br />
<br />
virtio-net<br />
}}<br />
<br />
If there are more modules to load per {{ic|*.conf}}, the module names can be separated by newlines. A good example are the [[VirtualBox#Installation steps for Arch Linux guests|VirtualBox Guest Additions]].<br />
<br />
Empty lines and lines starting with {{ic|#}} or {{ic|;}} are ignored.<br />
<br />
==== Hostname ====<br />
<br />
Set the [[Wikipedia:Hostname|hostname]] to your liking (e.g. ''arch''):<br />
<br />
# echo ''myhostname'' > /etc/hostname<br />
<br />
Add the same hostname to {{ic|/etc/hosts}}:<br />
<br />
{{hc|# nano /etc/hosts|<br />
#<br />
# /etc/hosts: static lookup table for host names<br />
#<br />
<br />
#<ip-address> <hostname.domain.org> <hostname><br />
127.0.0.1 localhost.localdomain localhost ''myhostname''<br />
::1 localhost.localdomain localhost<br />
<br />
# End of file<br />
}}<br />
<br />
=== Configure the network ===<br />
<br />
You need to configure the network again, but this time for your newly installed environment. The procedure and prerequisites are very similar to the one described [[#Establish an internet connection|above]], except we are going to make it persistent and automatically run at boot.<br />
<br />
As a first step, identify the network interface name you want to configure the connection for with {{ic|ip link}}. <br />
<br />
{{Note|<br />
* For more in-depth information on network configration, visit [[Network configuration]] and [[Wireless network configuration]].<br />
* If you would like to use the old interface naming scheme (ie. eth* and wlan*) you can accomplish this by creating an empty file at {{ic|/etc/udev/rules.d/80-net-setup-link.rules}} which will mask the file of the same name located under {{ic|/usr/lib/udev/rules.d}}.<br />
}}<br />
<br />
==== Wired ====<br />
<br />
===== Dynamic IP =====<br />
<br />
; Using dhcpcd<br />
<br />
If you only use a single fixed wired network connection, you do not need a network management service and can simply enable the {{ic|dhcpcd}} service for the interface:<br />
<br />
# systemctl enable dhcpcd@''interface_name''.service<br />
<br />
; Using netctl<br />
<br />
Copy a sample profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/ethernet-dhcp my_network<br />
<br />
Edit the profile as needed (update {{ic|Interface}} from {{ic|eth0}} to the interface name of the system. <br />
# nano my_network<br />
<br />
Enable the {{ic|my_network}} profile:<br />
<br />
# netctl enable my_network<br />
<br />
{{Note|You will get the message "Running in chroot, ignoring request.". This can be ignored for now.}}<br />
<br />
; Using netctl-ifplugd<br />
<br />
{{Warning|You cannot use this method in conjunction with explicitly enabling profiles, such as {{ic|netctl enable ''profile''}}.}}<br />
<br />
Alternatively, you can use {{ic|netctl-ifplugd}}, which gracefully handles dynamic connections to new networks.<br />
<br />
Install {{Pkg|ifplugd}}, which is required for {{ic|netctl-ifplugd}}:<br />
<br />
# pacman -S ifplugd<br />
<br />
Then enable for interface that you want:<br />
<br />
# systemctl enable netctl-ifplugd@''interface''.service<br />
<br />
{{Tip|[[netctl]] also provides {{ic|netctl-auto}}, which can be used to handle wired profiles in conjunction with {{ic|netctl-ifplugd}}.}}<br />
<br />
===== Static IP =====<br />
<br />
; Using netctl<br />
<br />
Copy a sample profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/ethernet-static my_network<br />
<br />
Edit the profile as needed (modify {{ic|Interface}}, {{ic|Address}}, {{ic|Gateway}} and {{ic|DNS}}):<br />
<br />
# nano my_network<br />
<br />
Notice the {{ic|/24}} in {{ic|Address}} which is the [[wikipedia:Classless Inter-Domain Routing#CIDR notation|CIDR notation]] of a {{ic|255.255.255.0}} netmask.<br />
<br />
Enable above created profile to start it at every boot:<br />
<br />
# netctl enable my_network<br />
<br />
; Using systemd-networkd<br />
<br />
See [[systemd-networkd]].<br />
<br />
==== Wireless ====<br />
<br />
{{Note|If your wireless adapter requires a firmware (as described in the above [[#Wireless|Establish an internet connection]] section and also in the article [[Wireless network configuration#Device driver]]), install the package containing your firmware. Most of the time, the {{Pkg|linux-firmware}} package will contain the needed firmware. Though for some devices, the required firmware might be in its own package. For example:<br />
{{bc|# pacman -S zd1211-firmware}}<br />
See [[Wireless network configuration#Installing driver/firmware]] for more info.}}<br />
<br />
Install {{Pkg|iw}} and {{Pkg|wpa_supplicant}} which you will need to connect to a network:<br />
<br />
# pacman -S iw wpa_supplicant<br />
<br />
===== Adding wireless networks =====<br />
<br />
; Using wifi-menu<br />
<br />
Install {{Pkg|dialog}}, which is required for {{ic|wifi-menu}}:<br />
<br />
# pacman -S dialog<br />
<br />
After finishing the rest of this installation and rebooting, you can connect to the network with {{ic|wifi-menu ''interface_name''}} (where {{ic|''interface_name''}} is the interface of your wireless chipset).<br />
<br />
# wifi-menu ''interface_name''<br />
<br />
{{Warning|This must be done '''after''' your reboot when you are no longer chrooted. The process spawned by this command will conflict with the one you have running outside of the chroot. Alternatively, you could just configure a network profile manually using the following templates so that you do not have to worry about using {{ic|wifi-menu}} at all.}}<br />
<br />
; Using manual netctl profiles<br />
<br />
Copy a network profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/wireless-wpa my-network<br />
<br />
Edit the profile as needed (modify {{ic|Interface}}, {{ic|ESSID}} and {{ic|Key}}):<br />
<br />
# nano my-network<br />
<br />
Enable above created profile to start it at every boot:<br />
<br />
# netctl enable my-network<br />
<br />
===== Connect automatically to known networks =====<br />
<br />
{{Warning|You cannot use this method in conjunction with explicitly enabling profiles, such as {{ic|netctl enable ''profile''}}.}}<br />
<br />
Install {{Pkg|wpa_actiond}}, which is required for {{ic|netctl-auto}}:<br />
<br />
# pacman -S wpa_actiond<br />
<br />
Enable the {{ic|netctl-auto}} service, which will connect to known networks and gracefully handle roaming and disconnects:<br />
<br />
# systemctl enable netctl-auto@''interface_name''.service<br />
<br />
{{Tip|[[netctl]] also provides {{ic|netctl-ifplugd}}, which can be used to handle wired profiles in conjunction with {{ic|netctl-auto}}.}}<br />
<br />
==== Analog modem, ISDN or PPPoE DSL ====<br />
<br />
For xDSL, dial-up and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Create an initial ramdisk environment ===<br />
<br />
{{Tip|Most users can skip this step and use the defaults provided in {{ic|mkinitcpio.conf}}. The initramfs image (from the {{ic|/boot}} folder) has already been generated based on this file when the {{Pkg|linux}} package (the Linux kernel) was installed earlier with ''pacstrap''.}}<br />
<br />
Here you need to set the right [[Mkinitcpio#HOOKS|hooks]] if the root is on a USB drive, if you use RAID, LVM, if using a multi-device Btrfs volumes as root, or if {{ic|/usr}} is on a separate partition.<br />
<br />
Edit {{ic|/etc/mkinitcpio.conf}} as needed and re-generate the initramfs image with:<br />
<br />
# mkinitcpio -p linux<br />
<br />
{{Note|Arch VPS installations on QEMU (e.g. when using {{ic|virt-manager}}) may need {{ic|virtio}} modules in {{ic|mkinitcpio.conf}} to be able to boot.<br />
{{hc|# nano /etc/mkinitcpio.conf|2=<br />
MODULES="virtio virtio_blk virtio_pci virtio_net"<br />
}}<br />
}}<br />
<br />
=== Set the root password ===<br />
<br />
Set the root password with:<br />
<br />
# passwd<br />
<br />
=== Install and configure a bootloader ===<br />
<br />
==== For BIOS motherboards ====<br />
<br />
For BIOS systems, several boot loaders are available, see [[Boot loaders]] for a complete list. Choose one as per your convenience. Here, two of the possibilities are given as examples:<br />
<br />
* [[Syslinux]] is (currently) limited to loading only files from the partition where it was installed. Its configuration file is considered to be easier to understand. An example configuration can be found in the [[Syslinux#Examples|syslinux]] article.<br />
* [[GRUB]] is more feature-rich and supports more complex scenarios. Its configuration file(s) is more similar to 'sh' scripting language, which may be difficult for beginners to manually write. It is recommended that they automatically generate one.<br />
<br />
===== Syslinux =====<br />
<br />
If you opted for a GUID partition table (GPT) for your hard drive earlier, you need to install the {{Pkg|gptfdisk}} package now for the installation of ''syslinux'' to work:<br />
<br />
# pacman -S gptfdisk<br />
<br />
Install the {{Pkg|syslinux}} package and then use the {{ic|syslinux-install_update}} script to automatically ''install'' the bootloader ({{ic|-i}}), mark the partition ''active'' by setting the boot flag ({{ic|-a}}), and install the ''MBR'' boot code ({{ic|-m}}):<br />
<br />
# pacman -S syslinux<br />
# syslinux-install_update -iam<br />
<br />
After installing Syslinux, configure {{ic|syslinux.cfg}} to point to the right root partition. This step is vital. If it points to the wrong partition, Arch Linux will not boot. Change {{ic|/dev/sda3}} to reflect your root partition (if you partitioned your drive as in [[#Prepare the storage drive|the example]], your root partition is {{ic|/dev/sda1}}).<br />
<br />
{{hc|# nano /boot/syslinux/syslinux.cfg|2=<br />
...<br />
LABEL arch<br />
...<br />
APPEND root='''/dev/sda3''' rw<br />
...<br />
LABEL archfallback<br />
...<br />
APPEND root='''/dev/sda3''' rw<br />
...<br />
}}<br />
<br />
If adding [[UUID]] rather than partition number the syntax is {{ic|1=APPEND root=UUID=''partition_uuid'' rw}}.<br />
<br />
For more information on configuring and using Syslinux, see [[Syslinux]].<br />
<br />
===== GRUB =====<br />
<br />
Install the {{Pkg|grub}} package and then run {{ic|grub-install}} to install the bootloader:<br />
<br />
# pacman -S grub<br />
# grub-install --target=i386-pc --recheck '''/dev/sda'''<br />
<br />
{{Note|<br />
* Change {{ic|/dev/sda}} to reflect the drive you installed Arch on. Do not append a partition number (do not use {{ic|sda''X''}}).<br />
* For GPT-partitioned drives on BIOS motherboards, you also need a "BIOS Boot Partition". See [[GRUB#GUID Partition Table (GPT) specific instructions|GPT-specific instructions]] in the GRUB page.<br />
* A sample {{ic|/boot/grub/grub.cfg}} gets installed as part of the {{Pkg|grub}} package, and subsequent {{ic|grub-*}} commands may not over-write it. Ensure that your intended changes are in {{ic|grub.cfg}}, rather than in {{ic|grub.cfg.new}} or some such file.<br />
}}<br />
<br />
While using a manually created {{ic|grub.cfg}} is absolutely fine, it is recommended that beginners automatically generate one:<br />
<br />
{{Tip|To automatically search for other operating systems on your computer, install {{Pkg|os-prober}} ({{ic|pacman -S os-prober}}) before running the next command.}}<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|It is possible that multiple redundant menu entries will be generated. See [[GRUB#Redundant_menu_entries]].}}<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
==== For UEFI motherboards ====<br />
<br />
For UEFI systems, several boot loaders are available, see [[Boot loaders]] for a complete list. Choose one as per your convenience. Here, two of the possibilities are given as examples:<br />
<br />
* [[gummiboot]] is a minimal UEFI Boot Manager which provides a menu for [[EFISTUB]] kernels and other UEFI applications.<br />
* [[GRUB]] is a more complete bootloader, useful if you run into problems with Gummiboot.<br />
<br />
No matter which one you choose, first install the {{Pkg|dosfstools}} package, so you can manipulate your EFI System Partition after installation:<br />
<br />
# pacman -S dosfstools<br />
<br />
{{Note|For UEFI boot, the drive needs to be GPT-partitioned and an [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] (512 MiB or larger, gdisk type {{ic|EF00}}, formatted with FAT32) must be present. In the following examples, this partition is assumed to be mounted at {{ic|/boot}}. If you have followed this guide from the beginning, you have already done all of these.}}<br />
<br />
===== Gummiboot =====<br />
<br />
Install the {{Pkg|gummiboot}} package and run {{ic|gummiboot install}} to install the bootloader to the EFI System Partition:<br />
<br />
# pacman -S gummiboot<br />
# gummiboot install<br />
<br />
{{Warning|Gummiboot and the Linux Kernel will not automatically update if your EFI System Partition is not mounted at {{ic|/boot}}.}}<br />
<br />
You will need to manually create a configuration file to add an entry for Arch Linux to the gummiboot manager. Create {{ic|/boot/loader/entries/arch.conf}} and add the following contents, replacing {{ic|/dev/sdaX}} with your '''root''' partition, usually {{ic|/dev/sda2}}:<br />
<br />
{{hc|# nano /boot/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root='''/dev/sdaX''' rw<br />
}}<br />
<br />
For more information on configuring and using gummiboot, see [[gummiboot]].<br />
<br />
===== GRUB =====<br />
{{warning| Some UEFI firmware requires that the Grub .efi stub be copied from its default location into a new {{ic|boot}} directory after installing and automatically configuring Grub. In such cases, not copying the stub will result in an unbootable installation, with the following error message displayed: "Reboot and Select proper Boot device or Insert Boot Media in selected Boot device and press a key". Review the [https://wiki.archlinux.org/index.php/Grub#EFI_path Grub EFI path] section in the [https://wiki.archlinux.org/index.php/Grub Grub] article for more information.}}<br />
<br />
Install the {{Pkg|grub}} and {{Pkg|efibootmgr}} packages and run {{ic|grub-install}} to install the bootloader:<br />
<br />
# pacman -S grub efibootmgr<br />
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck<br />
<br />
Next, while using a manually created {{ic|grub.cfg}} is absolutely fine, it is recommended that beginners automatically generate one:<br />
<br />
{{Tip|To automatically search for other operating systems on your computer, install {{Pkg|os-prober}} before running the next command. However ''os-prober'' is not known to properly detect UEFI OSes.}}<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
For more information on configuring and using GRUB in general, see [[GRUB]].<br />
<br />
=== Unmount the partitions and reboot ===<br />
<br />
Exit from the chroot environment:<br />
<br />
# exit<br />
<br />
{{Note|While partitions are unmounted automatically by ''systemd'' on shutdown, you may do so manually with {{ic|unmount -R /mnt}} as a safety measure. If the partition is "busy", you can find the cause with [[Wikipedia:fuser_(Unix)|fuser]].}}<br />
<br />
Reboot the computer:<br />
<br />
# reboot<br />
<br />
{{Tip|Be sure to remove the installation media, otherwise you will boot back into it.}}<br />
<br />
== Post-installation ==<br />
<br />
Your new Arch Linux base system is now a functional GNU/Linux environment ready to be built into whatever you wish or require for your purposes. You are now ''strongly'' advised to read [[General recommendations#System administration]] and [[General recommendations#Package management]].<br />
<br />
See the rest of the [[General recommendations]] article for post-installation tutorials like setting up a graphical user interface, sound or a touchpad.<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Bwidhttps://wiki.archlinux.org/index.php?title=LXDM&diff=336510LXDM2014-09-21T13:39:14Z<p>Bwid: /* Autologin */ Remove advise on how to set user passwordless. It is quite questionable security practice (ie. other service able to impersonate). If one really wants to do that, they should look it up in man passwd</p>
<hr />
<div>[[Category:Display managers]]<br />
[[it:LXDM]]<br />
[[ja:LXDM]]<br />
[[zh-CN:LXDM]]<br />
{{Related articles start}}<br />
{{Related|LXDE}}<br />
{{Related|Display manager}}<br />
{{Related articles end}}<br />
<br />
LXDM is a lightweight display manager for the [[LXDE]] [[desktop environment]]. The UI is implemented with [[GTK+]] 2.<br />
<br />
== Installation ==<br />
<br />
The {{Pkg|lxdm}} package is available in the [[official repositories]]. The development package, {{AUR|lxdm-git}}, is available in the [[AUR]].<br />
<br />
{{Pkg|lxdm}} provides the {{ic|lxdm}} [[systemd]] service. Enable it to start LXDM at boot.<br />
<br />
== Configuration ==<br />
<br />
The configuration files for LXDM are all located in {{ic|/etc/lxdm/}}. The main configuration file is {{ic|lxdm.conf}}, and is well documented in its comments. Another file, {{ic|Xsession}}, is the systemwide x session configuration file and should generally not be edited. The other files in this folder are all shell scripts, which are run when certain events happen in LXDM.<br />
<br />
These are:<br />
# {{ic|LoginReady}} is executed with root privileges when LXDM is ready to show the login window.<br />
# {{ic|PreLogin}} is run as root before logging a user in.<br />
# {{ic|PostLogin}} is run as the logged-in user right after he has logged in.<br />
# {{ic|PostLogout}} is run as the logged-in user right after he has logged out.<br />
# {{ic|PreReboot}} is run as root before rebooting with LXDM.<br />
# {{ic|PreShutdown}} is run as root before poweroff with LXDM.<br />
<br />
=== Default session ===<br />
<br />
It can be specified which session will be loaded when the users select the 'Default' session from the session list. Note that the user setting takes preference over global setting.<br />
<br />
==== Globally ====<br />
<br />
Edit {{ic|/etc/lxdm/lxdm.conf}} and change the session line to whatever session or DE is desired:<br />
<br />
{{bc|1=session=/usr/bin/startlxde}}<br />
<br />
Example using [[Xfce]]:<br />
{{bc|1=session=/usr/bin/startxfce4}}<br />
<br />
Example using [[Openbox]]:<br />
{{bc|1=session=/usr/bin/openbox-session}}<br />
<br />
Example using [[GNOME]]:<br />
{{bc|1=session=/usr/bin/gnome-session}}<br />
<br />
This is useful for themes that have no visible session selection box, and if experiencing trouble using autologin.<br />
<br />
==== Per user ====<br />
<br />
To define an individual user's preferred session, simply edit his/her respective {{ic|~/.dmrc}} to define the selection.<br />
<br />
Example: user1 wants Xfce4, user2 wants [[Cinnamon]], and user3 wants GNOME:<br />
<br />
For user1:<br />
[Desktop]<br />
Session=xfce<br />
<br />
For user2:<br />
[Desktop]<br />
Session=cinnamon<br />
<br />
For user3:<br />
[Desktop]<br />
Session=gnome<br />
<br />
=== Autologin ===<br />
<br />
To log in to one account automatically on startup, without providing a password, find the line in {{ic|/etc/lxdm/lxdm.conf}} that looks like this:<br />
#autologin=dgod<br />
Uncomment it, substituting the target user instead of ''dgod''.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Adding face icons ===<br />
<br />
A 96x96 px image (jpg or png) can optionally be displayed on a per-user basis replacing the stock icon. Simply copy or symlink the target image to {{ic|$HOME/.FACE}}. The {{Pkg|gnome-control-center}} package supplies some default icons suitable for the lxdm screen. Look under {{ic|/usr/share/pixmaps/faces}} after installing that package.<br />
<br />
{{Note|Users need not keep {{Pkg|gnome-control-center}} installed to use this images. Simply install it, copy them elsewhere, and remove it.}}<br />
<br />
=== Simultaneous users and switching users ===<br />
<br />
LXDM allows multiple users to be logged into different ttys at the same time. The following command is used to allow another user to login without logging out the current user:<br />
<br />
$ lxdm -c USER_SWITCH<br />
<br />
{{Note|When the new user logs in, his/her session is now on the NEXT tty from tty7. For example, user1 logs in and issues the USER_SWITCH command. Now user2 logs in. User2 will be on tty7 while user1 will be on tty1.}}<br />
<br />
If you use the [[Xfce]] desktop, the Switch User functionality of its Action Button panel item specifically looks for the ''gdmflexiserver'' executable in order to enable itself. If you provide it with an executable shell script {{ic|/usr/bin/gdmflexiserver}} consisting of<br />
<br />
#!/bin/sh<br />
/usr/bin/lxdm -c USER_SWITCH<br />
<br />
then user switching in Xfce should work fine also with LXDM.<br />
<br />
[[Xscreensaver]] can also perform this task. For more, see the [[Xscreensaver#LXDM|this section]] of the Xscreensaver article.<br />
<br />
=== Themes ===<br />
<br />
The LXDM themes are located in {{ic|/usr/share/lxdm/themes}}.<br />
<br />
There is only one theme provided with LXDM, namely Industrial. To display the background file {{ic|wave.svg}} which is part of this theme, make sure you have {{Pkg|librsvg}} installed.<br />
<br />
There are 2 themes provided with {{AUR|lxdm-git}}. ArchStripes and ArchDark.<br />
You can configure them on {{ic|/etc/lxdm/lxdm.conf}} in {{ic|1=theme=''theme_name''}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Incorrect logout handling ===<br />
<br />
You may find that, at times, LXDM fails to log out properly e.g. close down the session and kill user processes. This can result in programs continuing to run after logout and users not showing up in LXDM's user menu. To ensure that LXDM always logs out properly, edit {{ic|/etc/lxdm/lxdm.conf}} and enable the following line:<br />
<br />
reset=1<br />
<br />
This will restart the X server on logout, and this is the recommended way. <br />
<br />
Alternatively, you can add the following lines to the {{ic|/etc/lxdm/PostLogout}} script which will achieve the same effect:<br />
<br />
{{hc|/etc/lxdm/PostLogout|<br />
# Terminate current user session<br />
/usr/bin/loginctl terminate-session $XDG_SESSION_ID<br />
<br />
# Restart lxdm<br />
/usr/bin/systemctl restart lxdm.service<br />
}}<br />
<br />
=== XDMCP ===<br />
<br />
LXDM does not support the XDMCP protocol. A lightweight alternative that does is [[LightDM]].</div>Bwidhttps://wiki.archlinux.org/index.php?title=Talk:SLiM&diff=336504Talk:SLiM2014-09-21T13:09:17Z<p>Bwid: thank you</p>
<hr />
<div>== <s>Warn against usage?</s> ==<br />
<br />
On the #archlinux IRC Channel, sometimes users come in having problems with Slim. The response/advice is usually to switch to another DM.<br />
The channel factoid !slim states: "Don’t use it. It doesn’t play nicely with systemd, in part due to not being aware of sessions. It’s broken and has bugs that upstream refuses to fix."<br />
<br />
I wonder how true this is, and if we should put up a Warning with this text on top of the article.<br />
[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 08:46, 13 September 2014 (UTC)<br />
<br />
:The #archlinux channel "warns" against a host of other software, including [[netctl]], so you'd have to review all bot queries (anyone can add them as far as I know) and check them for factual accuracy... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:03, 13 September 2014 (UTC)<br />
<br />
::The factoid was created by demize, who is part of the channel op team. I'll see if i can ask for details.<br />
$ strcpy | !factinfo slim<br />
$ phrik | slim: Created by demize on 12:30 PM, May 25, 2014.<br />
::Even without evidence about technical concerns, here are facts which look to me might be enough to give some warning against its usage:<br />
::* While there is a sourceforge project page, there doesn't seem to be much on it besides the download (no bug tracker and no link to VCS)<br />
::* The linked Project-Homepage (http://slim.berlios.de/) is down. It has been for a while. I can't remember exactly how long it was when i last check. We can just wait 1-2 months, and then check again if anything has changed in that regard.<br />
::* Last entry in ChangeLog 2013.10.01. Compare that to lxde, which has a public git repository with 7 entries in the log in 2014.<br />
::[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 10:15, 13 September 2014 (UTC)<br />
<br />
:::Having followed a SLiM discussion on IRC, and with the above arguments I've added a warning. [https://wiki.archlinux.org/index.php?title=SLiM&diff=336425&oldid=335235] People can add links as appropriate, closing. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:44, 20 September 2014 (UTC)<br />
<br />
::::Thank you. Sorry for slacking off, i was initially meaning to look further into it, but then i couldn't be bothered. I think the way you wrote it is perfect. [[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 13:09, 21 September 2014 (UTC)</div>Bwidhttps://wiki.archlinux.org/index.php?title=Talk:LVM&diff=335548Talk:LVM2014-09-14T14:16:51Z<p>Bwid: /* PROS and CONS (citing needed) */</p>
<hr />
<div>== LVM-recovery section ==<br />
<br />
Would a section on LVM un-borkage be useful and/or within the scope of this article? [[User:Buhman|Buhman]] 13:45, 29 April 2012 (UTC)<br />
:All constructive contributions are welcome. However if you're going to simply rewrite some existing and well maintained documentation, it'd be better to just write an introduction and link to it; if instead you want to write an Arch-oriented section or something more original in general, then go for it :) -- [[User:Kynikos|Kynikos]] 09:53, 30 April 2012 (UTC)<br />
<br />
==<s> PROS and CONS (citing needed) </s>==<br />
<br />
Can anybody please come up with and elaborate on some of the cons as to what the drawbacks in performance and wear and tear would be when having multple LVM partitions spread and intertwined across several hard drives? (vs. keeping partitions spread evenly and limited to one drive only)<br />
<br />
Cons should be clearly listed on the main 'page' ("cons", or "disadvantages", maybe near "advantages")<br />
<br />
In fact, upon reading the 'advantages' section is what had me anticipating there would be something on disadvantages. I'm concerned about hard performance testing results. Has anyone seen any good data on this?<br />
<br />
:I did some work on this, consolidating the advantages which where listed in 2 different sections before. I picked some disadvantages which come to my mind, also some points from the german language version of the article.<br />
:No idea if there is any performance impact of lvm.<br />
:Also i removed 2 points in advantages:<br />
:* Name your VG and LV as you like -> Don't see that as adv. when compared to normal partitions. That you can name them is nice, it would be pretty mean if you could not.<br />
:* No need for an extended partition -> Never saw the extended/logical-partition thing as anything more than a minor wart from a user perspective.<br />
[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 12:25, 11 March 2013 (UTC)<br />
<br />
::I am closing this because i think the main focus of the article should be what LVM is, basic setup and some a little more advanced topics like Snapshots. However, going into performance comparission of Single-HD vs. Multiple-HD is: 1. Labor intensive, and i think nobody has time to do the work 2. Results would be Application specific. 3. The Scope of the article would get very large if the question where covered in detail. [[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 14:16, 14 September 2014 (UTC)<br />
<br />
==<s> Does swap really need to be on a contiguous volume? </s>==<br />
<br />
[[Lvm#Create logical volumes]] and [[Dm-crypt/Encrypting an entire system]] suggest to create contiguous logical volumes for swap with {{ic|lvcreate -C y}}, but is this really needed? And why? [http://unix.stackexchange.com/questions/58265/does-swap-need-to-be-on-a-contiguous-lvm-logical-volume], [https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s2-swap-creating-lvm2.html], [http://linuxlov3r.blogspot.com.au/2012/05/creating-swap-partition-in-lvm.html], [http://www.linuxask.com/questions/create-a-swap-partition-using-lvm] and [https://linux.web.cern.ch/linux/scientific4/docs/rhel-sag-en-4/s1-swap-adding.html] seem to bust the myth. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:58, 6 September 2014 (UTC)<br />
<br />
: Also [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/s1-swap-adding.html]. [[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 05:33, 6 September 2014 (UTC)<br />
<br />
::Interesting question. Imo it certainly is not needed, but was likely used here (back in 2008, wow:) because fragmentation (and resulting HDD seek times) otherwise may slow down the lv, and fragmented lv-swap (as ram replacement) slows down the system even more. That said I don't have a reference for this assumption, just seems logical to me. (In a multiple pv setup {{ic|-C y}} may be even [http://www.tldp.org/HOWTO/html_single/LVM-HOWTO/#mapmode disadvantageous] but that certainly goes too far for the article). For a similar reason (disk speed) swap was often created as the first lv on a fresh drive, because throughput on the outer HDD edge, which likely gets allocated first, is [http://superuser.com/questions/643013/are-partitions-to-the-inner-outer-edge-significantly-faster faster]. <br />
::I'd be +1 to mark the parameter as optional, or even remove it due to lack of reference for it. Other opinions (or a recent reference even)? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:26, 6 September 2014 (UTC)<br />
<br />
:::For the moment I've removed the flag where it was used. Maybe we can restore it in a Tip in [[LVM#Create logical volumes]] if we provide some justification, but certainly it doesn't belong in [[Dm-crypt/Encrypting an entire system]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:45, 7 September 2014 (UTC)<br />
<br />
::::Ok, but I'm curious why you write it "certainly" does not belong into the dm-crypt scenario? I'd argue (a) with [[Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS|LVM on LUKS]] you cannot run into problems with multiple pv's per se and (b) while the option was proposed as default in this article it might as well be used with dm-crypt as well (if there is any speed advantage to it, it does apply there too and crypto is unaffected). <br />
::::In any case, I looked into it again re creating a tip for this article and now think we should just leave it out (no tip). Reason: {{ic|-C y}} is linked to and overrides the default lvm allocation policy ({{ic|--alloc normal}}). The default policy will try contiguous allocation for a fresh setup/disk anyhow, but not fail. In case of a lack of contiguous extents it will try the next policy and following volumes "inherit" the policy from the vg. A problem, however, may arise if you later want to extent a volume which has "contiguous" set explicitly. Then you either have to move volumes [http://superuser.com/questions/435075/how-to-align-logical-volumes-on-contiguous-physical-extents] to create free contiguous extents or change the policy again [http://www.hostatic.ro/2010/02/15/lvm-inherit-and-contiguous-policies/]. Hence, {{ic|-C y}} explicitly is indeed bound to create problems and if add a tip for it, it must cover a lot incl. {{ic|--alloc}} and potential pitfalls. --> Let's leave it out of scope for this article and stick to defaults. It's a little deprecated anyway in times of SSDs and fast HDDs with cache. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 16:29, 12 September 2014 (UTC)<br />
<br />
:::::Thank you for your considerations, let's discard the Tip idea.<br />
:::::I wrote that -Cy doesn't "certainly" belong in that dm-crypt scenario because that example should be as simple as possible (it's not about LVM, it's about dm-crypt): if somebody wants a contiguous volume for some reason, he'll read LVM's documentation.<br />
:::::I think I can close this discussion. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:56, 13 September 2014 (UTC)<br />
<br />
::::::Thanks for the answer and sorry I reply after closing. Just wanted to note that I later figured we have a troubleshoot section here, which is a good place for the last links we collected above (also having in mind we had the option "-C y" for long). So I just went ahead and added the last links above to it with collected info to a troubleshoot item (instead of a tip): [https://wiki.archlinux.org/index.php?title=LVM&diff=335517&oldid=334209] to get it off the mind. <br />
:::::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:02, 14 September 2014 (UTC)</div>Bwidhttps://wiki.archlinux.org/index.php?title=Talk:LVM&diff=335545Talk:LVM2014-09-14T14:05:55Z<p>Bwid: /* PROS and CONS (citing needed) */ close</p>
<hr />
<div>== LVM-recovery section ==<br />
<br />
Would a section on LVM un-borkage be useful and/or within the scope of this article? [[User:Buhman|Buhman]] 13:45, 29 April 2012 (UTC)<br />
:All constructive contributions are welcome. However if you're going to simply rewrite some existing and well maintained documentation, it'd be better to just write an introduction and link to it; if instead you want to write an Arch-oriented section or something more original in general, then go for it :) -- [[User:Kynikos|Kynikos]] 09:53, 30 April 2012 (UTC)<br />
<br />
==<s> PROS and CONS (citing needed) </s>==<br />
<br />
Can anybody please come up with and elaborate on some of the cons as to what the drawbacks in performance and wear and tear would be when having multple LVM partitions spread and intertwined across several hard drives? (vs. keeping partitions spread evenly and limited to one drive only)<br />
<br />
Cons should be clearly listed on the main 'page' ("cons", or "disadvantages", maybe near "advantages")<br />
<br />
In fact, upon reading the 'advantages' section is what had me anticipating there would be something on disadvantages. I'm concerned about hard performance testing results. Has anyone seen any good data on this?<br />
<br />
:I did some work on this, consolidating the advantages which where listed in 2 different sections before. I picked some disadvantages which come to my mind, also some points from the german language version of the article.<br />
:No idea if there is any performance impact of lvm.<br />
:Also i removed 2 points in advantages:<br />
:* Name your VG and LV as you like -> Don't see that as adv. when compared to normal partitions. That you can name them is nice, it would be pretty mean if you could not.<br />
:* No need for an extended partition -> Never saw the extended/logical-partition thing as anything more than a minor wart from a user perspective.<br />
[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 12:25, 11 March 2013 (UTC)<br />
<br />
==<s> Does swap really need to be on a contiguous volume? </s>==<br />
<br />
[[Lvm#Create logical volumes]] and [[Dm-crypt/Encrypting an entire system]] suggest to create contiguous logical volumes for swap with {{ic|lvcreate -C y}}, but is this really needed? And why? [http://unix.stackexchange.com/questions/58265/does-swap-need-to-be-on-a-contiguous-lvm-logical-volume], [https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s2-swap-creating-lvm2.html], [http://linuxlov3r.blogspot.com.au/2012/05/creating-swap-partition-in-lvm.html], [http://www.linuxask.com/questions/create-a-swap-partition-using-lvm] and [https://linux.web.cern.ch/linux/scientific4/docs/rhel-sag-en-4/s1-swap-adding.html] seem to bust the myth. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:58, 6 September 2014 (UTC)<br />
<br />
: Also [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/s1-swap-adding.html]. [[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 05:33, 6 September 2014 (UTC)<br />
<br />
::Interesting question. Imo it certainly is not needed, but was likely used here (back in 2008, wow:) because fragmentation (and resulting HDD seek times) otherwise may slow down the lv, and fragmented lv-swap (as ram replacement) slows down the system even more. That said I don't have a reference for this assumption, just seems logical to me. (In a multiple pv setup {{ic|-C y}} may be even [http://www.tldp.org/HOWTO/html_single/LVM-HOWTO/#mapmode disadvantageous] but that certainly goes too far for the article). For a similar reason (disk speed) swap was often created as the first lv on a fresh drive, because throughput on the outer HDD edge, which likely gets allocated first, is [http://superuser.com/questions/643013/are-partitions-to-the-inner-outer-edge-significantly-faster faster]. <br />
::I'd be +1 to mark the parameter as optional, or even remove it due to lack of reference for it. Other opinions (or a recent reference even)? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:26, 6 September 2014 (UTC)<br />
<br />
:::For the moment I've removed the flag where it was used. Maybe we can restore it in a Tip in [[LVM#Create logical volumes]] if we provide some justification, but certainly it doesn't belong in [[Dm-crypt/Encrypting an entire system]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:45, 7 September 2014 (UTC)<br />
<br />
::::Ok, but I'm curious why you write it "certainly" does not belong into the dm-crypt scenario? I'd argue (a) with [[Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS|LVM on LUKS]] you cannot run into problems with multiple pv's per se and (b) while the option was proposed as default in this article it might as well be used with dm-crypt as well (if there is any speed advantage to it, it does apply there too and crypto is unaffected). <br />
::::In any case, I looked into it again re creating a tip for this article and now think we should just leave it out (no tip). Reason: {{ic|-C y}} is linked to and overrides the default lvm allocation policy ({{ic|--alloc normal}}). The default policy will try contiguous allocation for a fresh setup/disk anyhow, but not fail. In case of a lack of contiguous extents it will try the next policy and following volumes "inherit" the policy from the vg. A problem, however, may arise if you later want to extent a volume which has "contiguous" set explicitly. Then you either have to move volumes [http://superuser.com/questions/435075/how-to-align-logical-volumes-on-contiguous-physical-extents] to create free contiguous extents or change the policy again [http://www.hostatic.ro/2010/02/15/lvm-inherit-and-contiguous-policies/]. Hence, {{ic|-C y}} explicitly is indeed bound to create problems and if add a tip for it, it must cover a lot incl. {{ic|--alloc}} and potential pitfalls. --> Let's leave it out of scope for this article and stick to defaults. It's a little deprecated anyway in times of SSDs and fast HDDs with cache. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 16:29, 12 September 2014 (UTC)<br />
<br />
:::::Thank you for your considerations, let's discard the Tip idea.<br />
:::::I wrote that -Cy doesn't "certainly" belong in that dm-crypt scenario because that example should be as simple as possible (it's not about LVM, it's about dm-crypt): if somebody wants a contiguous volume for some reason, he'll read LVM's documentation.<br />
:::::I think I can close this discussion. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:56, 13 September 2014 (UTC)<br />
<br />
::::::Thanks for the answer and sorry I reply after closing. Just wanted to note that I later figured we have a troubleshoot section here, which is a good place for the last links we collected above (also having in mind we had the option "-C y" for long). So I just went ahead and added the last links above to it with collected info to a troubleshoot item (instead of a tip): [https://wiki.archlinux.org/index.php?title=LVM&diff=335517&oldid=334209] to get it off the mind. <br />
:::::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:02, 14 September 2014 (UTC)</div>Bwidhttps://wiki.archlinux.org/index.php?title=Talk:SLiM&diff=335252Talk:SLiM2014-09-13T10:15:02Z<p>Bwid: /* Warn against usage? */ some reasons</p>
<hr />
<div>== <s>Restructure</s> ==<br />
<br />
Planning slight re-structure to move "Shutdown, reboot, suspend, exit, launch terminal from SLiM" from "other options". This is to add a greater emphasis on these important commands (i.e. very useful where a mis-configuration results in being unable to progress past the login screen). {{Unsigned|14:16, 25 November 2013|Carlduff}}<br />
<br />
== Warn against usage? ==<br />
<br />
On the #archlinux IRC Channel, sometimes users come in having problems with Slim. The response/advice is usually to switch to another DM.<br />
The channel factoid !slim states: "Don’t use it. It doesn’t play nicely with systemd, in part due to not being aware of sessions. It’s broken and has bugs that upstream refuses to fix."<br />
<br />
I wonder how true this is, and if we should put up a Warning with this text on top of the article.<br />
[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 08:46, 13 September 2014 (UTC)<br />
<br />
:The #archlinux channel "warns" against a host of other software, including [[netctl]], so you'd have to review all bot queries (anyone can add them as far as I know) and check them for factual accuracy... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:03, 13 September 2014 (UTC)<br />
<br />
::The factoid was created by demize, who is part of the channel op team. I'll see if i can ask for details.<br />
$ strcpy | !factinfo slim<br />
$ phrik | slim: Created by demize on 12:30 PM, May 25, 2014.<br />
::Even without evidence about technical concerns, here are facts which look to me might be enough to give some warning against its usage:<br />
::* While there is a sourceforge project page, there doesn't seem to be much on it besides the download (no bug tracker and no link to VCS)<br />
::* The linked Project-Homepage (http://slim.berlios.de/) is down. It has been for a while. I can't remember exactly how long it was when i last check. We can just wait 1-2 months, and then check again if anything has changed in that regard.<br />
::* Last entry in ChangeLog 2013.10.01. Compare that to lxde, which has a public git repository with 7 entries in the log in 2014.<br />
::[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 10:15, 13 September 2014 (UTC)</div>Bwidhttps://wiki.archlinux.org/index.php?title=Talk:SLiM&diff=335219Talk:SLiM2014-09-13T08:46:36Z<p>Bwid: #archlinux IRC channel advises against usage of Slim</p>
<hr />
<div>Planning slight re-structure to move "Shutdown, reboot, suspend, exit, launch terminal from SLiM" from "other options". This is to add a greater emphasis on these important commands (i.e. very useful where a mis-configuration results in being unable to progress past the login screen).<br />
<br />
== Warn against usage? ==<br />
On the #archlinux IRC Channel, sometimes users come in having problems with Slim. The response/advice is usually to switch to another DM.<br />
The channel factoid !slim states: "Don’t use it. It doesn’t play nicely with systemd, in part due to not being aware of sessions. It’s broken and has bugs that upstream refuses to fix."<br />
<br />
I wonder how true this is, and if we should put up a Warning with this text on top of the article.<br />
[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 08:46, 13 September 2014 (UTC)</div>Bwidhttps://wiki.archlinux.org/index.php?title=GRUB&diff=334045GRUB2014-09-06T07:36:54Z<p>Bwid: Undo revision 334043 by Bwid (talk) actually scratch that, looking over it again changes are alright i guess. Pls write short edit Summarys to explain changes in the future.</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
<br />
Before attempting this method keep in mind that not all systems will be able to support this configuration, read more on [[GUID_Partition_Table#BIOS_systems|GUID partition tables]].<br />
<br />
On a BIOS/[[GPT]] configuration a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] is required. GRUB embeds its {{ic|core.img}} into this partition.<br />
<br />
{{Note| This additional partition is only needed for a GRUB, BIOS/GPT combination because on a [[GUID_Partition_Table|GPT]] system there is only a GPT Primary Header and Primary Partition table. This is opposed to newer [[Master_Boot_Record|MBR]] partitioning schemes that reserved the first mebibyte of disk space for the MBR and other bootloader necessities (like the {{ic|core.img}}), this space is commonly referred to as the post-MBR gap. For [[UEFI]] systems this extra partition is not required as no embedding of boot sectors takes place in that case.}}<br />
<br />
Create a mebibyte partition {{{ic|1=+1MiB}} with {{ic|gdisk}}) on the disk with no file system and type {{ic|ef02}} (or {{ic|bios_grub}} in {{ic|parted}}). This partition can be in any position order but has to be on the first 2 TiB of the disk. This partition needs to be created before installation. When the partition is ready, install the bootloader as per the instructions below and be sure to include the {{ic|1=--target=i386-pc}} option (as GRUB may mistaken the configuration as EFI-GPT).<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 4 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to external USB stick|Install to external USB stick]] (for recovery)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to external USB stick =====<br />
Assume your USB stick's first partition is FAT32 and it's partition is /dev/sdy1<br />
<br />
# mkdir -p /tmp/y ; mount /dev/sdy1 /tmp/y <br />
# grub-install --target=i386-pc --recheck --debug --boot-directory=/tmp/y/boot /dev/sdy<br />
# grub-mkconfig -o /tmp/y/boot/grub/grub.cfg<br />
<br />
# optional, backup config files of grub.cfg<br />
# mkdir -p /tmp/y/etc/default<br />
# cp /etc/default/grub /tmp/y/etc/default<br />
# cp -a /etc/grub.d /tmp/y/etc<br />
<br />
# sync ; umount /tmp/y<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partition (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed. Do not forget to [[#Generating main configuration file|generate the main configuration file]].<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath}/grub.cfg should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
{{Warning|You may find that the {{ic|grub.cfg}} file is not loaded due to {{ic|${cmdpath} }} missing a slash (i.e. {{ic|(hd1,msdos2)EFI/Boot}} instead of {{ic|(hd1,msdos2)/EFI/Boot}}) and so you are dropped into a GRUB shell. If this happens determine what {{ic|${cmdpath} }} is set to ({{ic|echo ${cmdpath} }}) and then load the config file manually (e.g. {{ic|configfile (hd1,msdos2)/EFI/Boot/grub.cfg}}).}}<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Disable Submenu ===<br />
If you have multiple kernels installed, say linux and linux-lts, by default {{ic|grub-mkconfig}} groups them in a submenu. <br />
If you do not like this behaviour you can go back to one single menu by adding the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_SUBMENU=y<br />
<br />
=== Root encryption ===<br />
<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
See [[Dm-crypt/System Configuration#Boot loader]] for more details.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
{{Accuracy|1=The following step was added with [https://wiki.archlinux.org/index.php?title=GRUB&diff=184194&oldid=183020], but there is not a clear reason to disable the usage of UUIDs for the root file system.}}<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Tip|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode (as per alternate method):<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the uefi bitness. It '''WILL NOT WORK''' in bios installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations|this]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations|this]] for more info.}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands. {{ic|$fs_uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually C:). In {{ic|blkid}} output, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
{{Note|These menuentries will work only in Legacy BIOS boot mode. It WILL NOT WORK in uefi installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations]].}}<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting ISO9660 image file directly via GRUB ===<br />
{{Poor writing|The only boxes used should be code blocks, otherwise the section will be unreadable. Anything else should be plain text.}}<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO image file and update the boot menu accordingly, for example:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Here are some examples about booting different distributions' LiveCD.<br />
{{Note|<br />
* The following examples assume the ISO image exists at {{ic|/boot/iso}} on {{ic|hd1,2}}(i.e.{{ic|/dev/sdb2}}).<br />
* Not all distributions' ISO image can boot that way (e.g. CentOS ≤ 6.5), so when you try to boot other distribution's ISO which is or not listed here and it is stuck, please looking for related documentation and wiki pages or ask for help in the related community.}}<br />
{{tip|The prefix {{ic|'''(hd1,2)'''}} before {{ic|$isofile}}(also {{ic|$initrdfile}} and any other similar) can be omitted when the grub directory(the directory includes GRUB config files and modules, e.g. {{ic|/boot/grub}}) and the ISO images are in the same partition. This is recommended for thumbdrives.}}<br />
<br />
==== Arch Linux ====<br />
{{Tip|If you want to boot into a 32-bit system, replace {{ic|x86_64}} with {{ic|i686}}.}}<br />
===== monthly release =====<br />
{{bc|1=menuentry '[loopback]archlinux-2014.09.03-dual.iso' {<br />
set isofile='/boot/iso/archlinux-2014.09.03-dual.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/arch/boot/'''x86_64'''/vmlinuz archisolabel=ARCH_'''201409''' img_dev='''/dev/sdb2''' img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/'''x86_64'''/archiso.img<br />
}<br />
}}<br />
{{note|<br />
* It's recommend for thumbdrives to use [[Persistent block device naming|a persistent name]] instead of {{ic|/dev/sd'''''xY'''''}} for the {{ic|img_dev}} parameter, e.g. {{ic|1=img_dev=/dev/disk/by-label/MYUSBSTICK}} (or {{ic|1=img_label=MYUSBSTICK}}).<br />
* As the official monthly release build script [https://projects.archlinux.org/archiso.git/tree/configs/releng/build.sh#n6 defines], you need to edit the label string after {{ic|1=archisolabel=}} when you use a newer monthly released ISO image.<br />
* For a complete list of archiso boot parameters, please see its [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams documentation].}}<br />
<br />
===== archboot =====<br />
See also: [[Archboot]]<br />
{{bc|1=<br />
menuentry '[loopback]archlinux-2014.08-1-archboot' {<br />
set isofile='/boot/iso/archlinux-2014.08-1-archboot.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/boot/vmlinuz_'''x86_64''' iso_loop_dev='''/dev/sdb2''' iso_loop_path=$isofile<br />
initrd (loop)/boot/initramfs_'''x86_64'''.img<br />
}<br />
}}<br />
<br />
==== CentOS ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-DVD' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-DVD.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|The boot parameter {{ic|1=inst.stage2=hd:}} which is used by [https://fedoraproject.org/wiki/Anaconda anaconda], is similar to [[fstab]]'s first field(fs_spec):<br />
* {{ic|1=inst.stage2=hd:/dev/sd'''''xY'''''}}<br />
* {{ic|1=inst.stage2=hd:LABEL=MYUSBSTICK}}<br />
* {{ic|1=inst.stage2=hd:UUID=00000000-0000-0000-0000-0000deadbeef}}<br />
}}<br />
<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-GnomeLive' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-GnomeLive.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=CentOS-7-live-GNOME-x86_64 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Debian ====<br />
===== Stock install medium =====<br />
{{note|To install debian from any stock install medium on a hard disk(or usb stick), it's necessary to use a different initramfs instead of the default one on the installation medium(it is located at {{ic|(loop)/install.amd/initrd.gz}}). If you boot with the default one, the [https://www.debian.org/devel/debian-installer/ debian-installer] will unable to find or mount the proper iso image for installation. Please download the initramfs for hard disk installation from [https://mirrors.kernel.org/debian/dists/stable/main/installer-amd64/current/images/hd-media/initrd.gz an official mirror site], put it in the same directory with the image file and give it a suitable name({{ic|debian-7.6.0-amd64-DVD-1.hdd.initrd.gz}} in this example).}}<br />
{{bc|1=menuentry '[loopback]debian-7.6.0-amd64-DVD-1' {<br />
set isofile='/boot/iso/debian-7.6.0-amd64-DVD-1.iso'<br />
set initrdfile='/boot/iso/debian-7.6.0-amd64-DVD-1.hdd.initrd.gz'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/install.amd/vmlinuz vga=791 iso-scan/ask_second_pass=true iso-scan/filename=$isofile<br />
initrd '''(hd1,2)'''$initrdfile<br />
}<br />
}}<br />
===== Live install medium =====<br />
{{bc|1=menuentry '[loopback]debian-live-7.6.0-amd64-xfce-desktop' {<br />
set isofile='/boot/iso/debian-live-7.6.0-amd64-xfce-desktop.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live config fromiso='''/dev/sdb2'''/$isofile<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
{{note|It's also OK to use {{ic|1=findiso=$isofile}} instead of the longer {{ic|1=fromiso=/dev/disk/by-.../.../$isofile}}. Anyway, using {{ic|1=fromiso=}} instead of {{ic|1=findiso=}} may speed up the initialization progress because it avoids unnecessary mounting.}}<br />
<br />
==== Fedora ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-20-x86_64-DVD' {<br />
set isofile='/boot/iso/Fedora-20-x86_64-DVD.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|For a list of [https://fedoraproject.org/wiki/Anaconda anaconda] boot parameters, please see this [https://git.fedorahosted.org/cgit/anaconda.git/tree/docs/boot-options.txt documentation].}}<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-Live-Desktop-x86_64-20-1' {<br />
set isofile='/boot/iso/Fedora-Live-Desktop-x86_64-20-1.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-1 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Kali Linux ====<br />
{{bc|1=menuentry '[loopback]kali-linux-1.0.7-amd64' {<br />
set isofile='/boot/iso/kali-linux-1.0.7-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live findiso=$isofile noconfig=sudo username=root hostname=kali<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
<br />
==== openSUSE ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-DVD-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-DVD-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux install=hd:$isofile<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
===== LiveCD =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-KDE-Live-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-KDE-Live-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux isofrom_device='''/dev/sdb2''' isofrom_system=$isofile LANG='''en_US.UTF-8'''<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
<br />
==== Sabayon ====<br />
{{bc|1=<br />
menuentry '[loopback]Sabayon_Linux_14.05_amd64_KDE' {<br />
set isofile='/boot/iso/Sabayon_Linux_14.05_amd64_KDE.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/sabayon root=/dev/ram0 aufs cdroot locale='''en_US''' loop=/livecd.squashfs looptype=squashfs isoboot=$isofile<br />
initrd (loop)/boot/sabayon.igz<br />
}<br />
}}<br />
<br />
==== Slackware Linux ====<br />
{{bc|1=menuentry '[loopback]slackware64-14.1-install-dvd' {<br />
set isofile='/boot/iso/slackware64-14.1-install-dvd.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/kernels/huge.s/bzImage printk.time=0<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
<br />
==== Ubuntu ====<br />
{{bc|1=menuentry '[loopback]ubuntu-14.04-desktop-amd64' {<br />
set isofile='/boot/iso/ubuntu-14.04-desktop-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile locale='''en_US.UTF-8'''<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
}}<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/40_custom}}:<br />
<br />
{{hc|/etc/grub.d/40_custom|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created and made executable:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
Make that file executable and then regenerate your grub config:<br />
chmod a+x /etc/grub.d/31_hold_shift<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>Bwidhttps://wiki.archlinux.org/index.php?title=GRUB&diff=334043GRUB2014-09-06T06:56:29Z<p>Bwid: revert changes. Gen2ly: your edit changed several things at once. Please brake your edits up in atomic parts. I think your changes to technical explanation are incorrect, please discuss them first on Talk page</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
<br />
On a BIOS - [[GPT]] configuration, a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] is required. GRUB embeds its {{ic|core.img}} into this partition.<br />
<br />
{{Note| This partition is only needed for the GRUB - BIOS - GPT combination. The reason is that on a [[Master_Boot_Record|MBR]] system, GRUB uses the so called post-MBR gap to embed the image. On a [[GUID_Partition_Table|GPT]] system, the spot where the post-MBR gap was is taken over by the GPT Primary Header and Primary Partition table, so GRUB can no longer use it for this purpose. This extra partition is also not required if the system is [[UEFI]] based, as no embedding of boot sectors takes place in that case.<br />
}}<br />
<br />
Create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no file system. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. In rare cases you may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes will refuse to boot.<br />
<br />
{{Tip|<br />
* You will probably need to explicitly set the {{ic|grub-install}} target to {{ic|i386-pc}} using {{ic|<nowiki>--target=i386-pc</nowiki>}}. Otherwise {{ic|grub-install}} sometimes guesses that your configuration is EFI-GPT.<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 4 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to external USB stick|Install to external USB stick]] (for recovery)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to external USB stick =====<br />
Assume your USB stick's first partition is FAT32 and it's partition is /dev/sdy1<br />
<br />
# mkdir -p /tmp/y ; mount /dev/sdy1 /tmp/y <br />
# grub-install --target=i386-pc --recheck --debug --boot-directory=/tmp/y/boot /dev/sdy<br />
# grub-mkconfig -o /tmp/y/boot/grub/grub.cfg<br />
<br />
# optional, backup config files of grub.cfg<br />
# mkdir -p /tmp/y/etc/default<br />
# cp /etc/default/grub /tmp/y/etc/default<br />
# cp -a /etc/grub.d /tmp/y/etc<br />
<br />
# sync ; umount /tmp/y<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partition (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed. Do not forget to [[#Generating main configuration file|generate the main configuration file]].<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath}/grub.cfg should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
{{Warning|You may find that the {{ic|grub.cfg}} file is not loaded due to {{ic|${cmdpath} }} missing a slash (i.e. {{ic|(hd1,msdos2)EFI/Boot}} instead of {{ic|(hd1,msdos2)/EFI/Boot}}) and so you are dropped into a GRUB shell. If this happens determine what {{ic|${cmdpath} }} is set to ({{ic|echo ${cmdpath} }}) and then load the config file manually (e.g. {{ic|configfile (hd1,msdos2)/EFI/Boot/grub.cfg}}).}}<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Disable Submenu ===<br />
If you have multiple kernels installed, say linux and linux-lts, by default {{ic|grub-mkconfig}} groups them in a submenu. <br />
If you do not like this behaviour you can go back to one single menu by adding the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_SUBMENU=y<br />
<br />
=== Root encryption ===<br />
<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
See [[Dm-crypt/System Configuration#Boot loader]] for more details.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
{{Accuracy|1=The following step was added with [https://wiki.archlinux.org/index.php?title=GRUB&diff=184194&oldid=183020], but there is not a clear reason to disable the usage of UUIDs for the root file system.}}<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Tip|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode (as per alternate method):<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the uefi bitness. It '''WILL NOT WORK''' in bios installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations|this]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations|this]] for more info.}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands. {{ic|$fs_uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually C:). In {{ic|blkid}} output, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
{{Note|These menuentries will work only in Legacy BIOS boot mode. It WILL NOT WORK in uefi installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations]].}}<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting ISO9660 image file directly via GRUB ===<br />
{{Poor writing|The only boxes used should be code blocks, otherwise the section will be unreadable. Anything else should be plain text.}}<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO image file and update the boot menu accordingly, for example:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Here are some examples about booting different distributions' LiveCD.<br />
{{Note|<br />
* The following examples assume the ISO image exists at {{ic|/boot/iso}} on {{ic|hd1,2}}(i.e.{{ic|/dev/sdb2}}).<br />
* Not all distributions' ISO image can boot that way (e.g. CentOS ≤ 6.5), so when you try to boot other distribution's ISO which is or not listed here and it is stuck, please looking for related documentation and wiki pages or ask for help in the related community.}}<br />
{{tip|The prefix {{ic|'''(hd1,2)'''}} before {{ic|$isofile}}(also {{ic|$initrdfile}} and any other similar) can be omitted when the grub directory(the directory includes GRUB config files and modules, e.g. {{ic|/boot/grub}}) and the ISO images are in the same partition. This is recommended for thumbdrives.}}<br />
<br />
==== Arch Linux ====<br />
{{Tip|If you want to boot into a 32-bit system, replace {{ic|x86_64}} with {{ic|i686}}.}}<br />
===== monthly release =====<br />
{{bc|1=menuentry '[loopback]archlinux-2014.09.03-dual.iso' {<br />
set isofile='/boot/iso/archlinux-2014.09.03-dual.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/arch/boot/'''x86_64'''/vmlinuz archisolabel=ARCH_'''201409''' img_dev='''/dev/sdb2''' img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/'''x86_64'''/archiso.img<br />
}<br />
}}<br />
{{note|<br />
* It's recommend for thumbdrives to use [[Persistent block device naming|a persistent name]] instead of {{ic|/dev/sd'''''xY'''''}} for the {{ic|img_dev}} parameter, e.g. {{ic|1=img_dev=/dev/disk/by-label/MYUSBSTICK}} (or {{ic|1=img_label=MYUSBSTICK}}).<br />
* As the official monthly release build script [https://projects.archlinux.org/archiso.git/tree/configs/releng/build.sh#n6 defines], you need to edit the label string after {{ic|1=archisolabel=}} when you use a newer monthly released ISO image.<br />
* For a complete list of archiso boot parameters, please see its [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams documentation].}}<br />
<br />
===== archboot =====<br />
See also: [[Archboot]]<br />
{{bc|1=<br />
menuentry '[loopback]archlinux-2014.08-1-archboot' {<br />
set isofile='/boot/iso/archlinux-2014.08-1-archboot.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/boot/vmlinuz_'''x86_64''' iso_loop_dev='''/dev/sdb2''' iso_loop_path=$isofile<br />
initrd (loop)/boot/initramfs_'''x86_64'''.img<br />
}<br />
}}<br />
<br />
==== CentOS ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-DVD' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-DVD.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|The boot parameter {{ic|1=inst.stage2=hd:}} which is used by [https://fedoraproject.org/wiki/Anaconda anaconda], is similar to [[fstab]]'s first field(fs_spec):<br />
* {{ic|1=inst.stage2=hd:/dev/sd'''''xY'''''}}<br />
* {{ic|1=inst.stage2=hd:LABEL=MYUSBSTICK}}<br />
* {{ic|1=inst.stage2=hd:UUID=00000000-0000-0000-0000-0000deadbeef}}<br />
}}<br />
<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-GnomeLive' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-GnomeLive.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=CentOS-7-live-GNOME-x86_64 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Debian ====<br />
===== Stock install medium =====<br />
{{note|To install debian from any stock install medium on a hard disk(or usb stick), it's necessary to use a different initramfs instead of the default one on the installation medium(it is located at {{ic|(loop)/install.amd/initrd.gz}}). If you boot with the default one, the [https://www.debian.org/devel/debian-installer/ debian-installer] will unable to find or mount the proper iso image for installation. Please download the initramfs for hard disk installation from [https://mirrors.kernel.org/debian/dists/stable/main/installer-amd64/current/images/hd-media/initrd.gz an official mirror site], put it in the same directory with the image file and give it a suitable name({{ic|debian-7.6.0-amd64-DVD-1.hdd.initrd.gz}} in this example).}}<br />
{{bc|1=menuentry '[loopback]debian-7.6.0-amd64-DVD-1' {<br />
set isofile='/boot/iso/debian-7.6.0-amd64-DVD-1.iso'<br />
set initrdfile='/boot/iso/debian-7.6.0-amd64-DVD-1.hdd.initrd.gz'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/install.amd/vmlinuz vga=791 iso-scan/ask_second_pass=true iso-scan/filename=$isofile<br />
initrd '''(hd1,2)'''$initrdfile<br />
}<br />
}}<br />
===== Live install medium =====<br />
{{bc|1=menuentry '[loopback]debian-live-7.6.0-amd64-xfce-desktop' {<br />
set isofile='/boot/iso/debian-live-7.6.0-amd64-xfce-desktop.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live config fromiso='''/dev/sdb2'''/$isofile<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
{{note|It's also OK to use {{ic|1=findiso=$isofile}} instead of the longer {{ic|1=fromiso=/dev/disk/by-.../.../$isofile}}. Anyway, using {{ic|1=fromiso=}} instead of {{ic|1=findiso=}} may speed up the initialization progress because it avoids unnecessary mounting.}}<br />
<br />
==== Fedora ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-20-x86_64-DVD' {<br />
set isofile='/boot/iso/Fedora-20-x86_64-DVD.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|For a list of [https://fedoraproject.org/wiki/Anaconda anaconda] boot parameters, please see this [https://git.fedorahosted.org/cgit/anaconda.git/tree/docs/boot-options.txt documentation].}}<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-Live-Desktop-x86_64-20-1' {<br />
set isofile='/boot/iso/Fedora-Live-Desktop-x86_64-20-1.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-1 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Kali Linux ====<br />
{{bc|1=menuentry '[loopback]kali-linux-1.0.7-amd64' {<br />
set isofile='/boot/iso/kali-linux-1.0.7-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live findiso=$isofile noconfig=sudo username=root hostname=kali<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
<br />
==== openSUSE ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-DVD-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-DVD-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux install=hd:$isofile<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
===== LiveCD =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-KDE-Live-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-KDE-Live-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux isofrom_device='''/dev/sdb2''' isofrom_system=$isofile LANG='''en_US.UTF-8'''<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
<br />
==== Sabayon ====<br />
{{bc|1=<br />
menuentry '[loopback]Sabayon_Linux_14.05_amd64_KDE' {<br />
set isofile='/boot/iso/Sabayon_Linux_14.05_amd64_KDE.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/sabayon root=/dev/ram0 aufs cdroot locale='''en_US''' loop=/livecd.squashfs looptype=squashfs isoboot=$isofile<br />
initrd (loop)/boot/sabayon.igz<br />
}<br />
}}<br />
<br />
==== Slackware Linux ====<br />
{{bc|1=menuentry '[loopback]slackware64-14.1-install-dvd' {<br />
set isofile='/boot/iso/slackware64-14.1-install-dvd.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/kernels/huge.s/bzImage printk.time=0<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
<br />
==== Ubuntu ====<br />
{{bc|1=menuentry '[loopback]ubuntu-14.04-desktop-amd64' {<br />
set isofile='/boot/iso/ubuntu-14.04-desktop-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile locale='''en_US.UTF-8'''<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
}}<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/40_custom}}:<br />
<br />
{{hc|/etc/grub.d/40_custom|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created and made executable:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
Make that file executable and then regenerate your grub config:<br />
chmod a+x /etc/grub.d/31_hold_shift<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>Bwidhttps://wiki.archlinux.org/index.php?title=Talk:LVM&diff=334039Talk:LVM2014-09-06T05:33:49Z<p>Bwid: /* Does swap really need to be on a contiguous volume? */</p>
<hr />
<div><br />
== Templates ==<br />
<br />
I notice this article has several areas marked with '''Attention:''', '''Information:''', '''Hint:''', etc. Before I go on an editing frenzy, are templates (like <nowiki>{{Warning|...}}</nowiki>) the preferred format? If so, I will quite happily go through and change all of them. I'm new to this wiki, so I thought I'd ask before stirring up dust. :-) [[User:Infiniteh|Infiniteh]] 16:56, 27 August 2010 (EDT)<br />
<br />
:I went ahead and added templates to the first few sections and did some minor restructuring. However, I may revert my changes (or rethink them). All these colored text boxes seem to make the page less readable... Any thoughts? [[User:Infiniteh|Infiniteh]] 21:11, 28 August 2010 (EDT)<br />
<br />
::The page looks nicer with new templates :). I think a few colored text boxes could be removed. For example: "Note: You may need to load the device-mapper kernel module (modprobe dm-mod) for the above commands to succeed" could be easily removed, because that info is stated at the begining of the article. I think that warnings should stay though. [[User:Billy|billy]] 04:46, 5 September 2010 (EDT)<br />
<br />
== LVM-recovery section ==<br />
<br />
Would a section on LVM un-borkage be useful and/or within the scope of this article? [[User:Buhman|Buhman]] 13:45, 29 April 2012 (UTC)<br />
:All constructive contributions are welcome. However if you're going to simply rewrite some existing and well maintained documentation, it'd be better to just write an introduction and link to it; if instead you want to write an Arch-oriented section or something more original in general, then go for it :) -- [[User:Kynikos|Kynikos]] 09:53, 30 April 2012 (UTC)<br />
<br />
<br />
== PROS and CONS (citing needed) ==<br />
<br />
Can anybody please come up with and elaborate on some of the cons as to what the drawbacks in performance and wear and tear would be when having multple LVM partitions spread and intertwined across several hard drives? (vs. keeping partitions spread evenly and limited to one drive only)<br />
<br />
Cons should be clearly listed on the main 'page' ("cons", or "disadvantages", maybe near "advantages")<br />
<br />
In fact, upon reading the 'advantages' section is what had me anticipating there would be something on disadvantages. I'm concerned about hard performance testing results. Has anyone seen any good data on this?<br />
<br />
<br />
: I did some work on this, consolidating the advantages which where listed in 2 different sections before. I picked some disadvantages which come to my mind, also some points from the german language version of the article.<br />
: No idea if there is any performance impact of lvm.<br />
: Also i removed 2 points in advantages:<br />
: * Name your VG and LV as you like -> Don't see that as adv. when compared to normal partitions. That you can name them is nice, it would be pretty mean if you could not.<br />
: * No need for an extended partition -> Never saw the extended/logical-partition thing as anything more than a minor wart from a user perspective.<br />
[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 12:25, 11 March 2013 (UTC)<br />
<br />
== Does swap really need to be on a contiguous volume? ==<br />
<br />
[[Lvm#Create logical volumes]] and [[Dm-crypt/Encrypting an entire system]] suggest to create contiguous logical volumes for swap with {{ic|lvcreate -C y}}, but is this really needed? And why? [http://unix.stackexchange.com/questions/58265/does-swap-need-to-be-on-a-contiguous-lvm-logical-volume], [https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s2-swap-creating-lvm2.html], [http://linuxlov3r.blogspot.com.au/2012/05/creating-swap-partition-in-lvm.html], [http://www.linuxask.com/questions/create-a-swap-partition-using-lvm] and [https://linux.web.cern.ch/linux/scientific4/docs/rhel-sag-en-4/s1-swap-adding.html] seem to bust the myth. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:58, 6 September 2014 (UTC)<br />
: Also [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/s1-swap-adding.html]. [[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 05:33, 6 September 2014 (UTC)</div>Bwidhttps://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=333756Beginners' guide2014-09-04T09:10:53Z<p>Bwid: /* Example */ Advise to use plain lsblk first, since it includes the SIZE column, which lsblk -f does not. I think we can get away without mentioning the -o <columnlist> option, because "lsblk" / "lsblk -f" combination includes all the important columns.</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:Beginners' Guide]]<br />
[[bg:Beginners' Guide]]<br />
[[cs:Beginners' Guide]]<br />
[[da:Beginners' Guide]]<br />
[[de:Anleitung für Einsteiger]]<br />
[[el:Beginners' Guide]]<br />
[[es:Beginners' Guide]]<br />
[[fa:راهنمای تازهکارها]]<br />
[[fr:Installation]]<br />
[[he:Beginners' Guide]]<br />
[[hr:Beginners' Guide]]<br />
[[hu:Beginners' Guide]]<br />
[[id:Beginners' Guide]]<br />
[[it:Beginners' Guide]]<br />
[[ja:Beginners' Guide]]<br />
[[ko:Beginners' Guide]]<br />
[[lt:Beginners' Guide]]<br />
[[nl:Beginners' Guide]]<br />
[[pl:Beginners' Guide]]<br />
[[pt:Beginners' Guide]]<br />
[[ro:Ghidul începătorilor]]<br />
[[ru:Beginners' guide]]<br />
[[sk:Beginners' Guide]]<br />
[[sr:Beginners' Guide]]<br />
[[sv:Nybörjarguiden]]<br />
[[tr:Yeni başlayanlar rehberi]]<br />
[[uk:Beginners' Guide]]<br />
[[zh-CN:Beginners' guide]]<br />
[[zh-TW:Beginners' Guide]]<br />
{{Related articles start}}<br />
{{Related|:Category:Accessibility}}<br />
{{Related|Installation guide}}<br />
{{Related|Diskless system}}<br />
{{Related|Install from SSH}}<br />
{{Related|General recommendations}}<br />
{{Related|General troubleshooting}}<br />
{{Related articles end}}<br />
This document will guide you through the process of installing [[Arch Linux]] using the [https://projects.archlinux.org/arch-install-scripts.git/ Arch Install Scripts]. Before installing, you are advised to skim over the [[FAQ]].<br />
<br />
The community-maintained [[Main page|ArchWiki]] is the primary resource that should be consulted if issues arise. The [[IRC channel]] (irc://irc.freenode.net/#archlinux) and the [https://bbs.archlinux.org/ forums] are also excellent resources if an answer cannot be found elsewhere. In accordance with [[the Arch Way]], you are encouraged to type {{ic|man ''command''}} to read the {{ic|man}} page of any command you are unfamiliar with.<br />
<br />
== Preparation ==<br />
<br />
{{Note|If you wish to install from an existing GNU/Linux distribution, please see [[Install from Existing Linux]]. This can be useful particularly if you plan to install Arch via [[VNC]] or [[SSH]] remotely. Users seeking to perform the Arch Linux installation remotely via an [[SSH]] connection should read [[Install from SSH]] for additional tips.}}<br />
<br />
=== System requirements ===<br />
<br />
Arch Linux should run on any [[Wikipedia:P6 (microarchitecture)|i686]] compatible machine with a minimum of 64 MB RAM. A basic installation with all packages from the {{Grp|base}} group should take less than 800 MB of disk space. If you are working with limited space, this can be trimmed down considerably, but you will have to know what you are doing.<br />
<br />
=== Prepare the latest installation medium ===<br />
<br />
The latest release of the installation media can be obtained from the [https://archlinux.org/download/ Download] page. Note that the single ISO image supports both 32 and 64-bit architectures. It is highly recommended to always use the latest ISO image.<br />
<br />
{{Tip|The [https://downloads.archlinux.de/iso/archboot/latest archboot] ISO images can take several steps explained in this guide [[Archboot#Interactive_setup_features|interactively]]. See [[Archboot]] for details.}}<br />
<br />
* Install images are signed and it is highly recommended to verify their signature before use. Dowload the ''.sig'' file from the download page (or one of the mirrors listed there) to the same directory as the ''.iso'' file. On Arch Linux, use {{ic|pacman-key -v ''iso-file''.sig}} as root; in other environments make use, still as root, of gpg2 directly with {{ic|gpg2 --verify ''iso-file''.sig}}. The file integrity checksums md5 and sha1 are also provided {{Note|The gpg2 verification will fail if you have not downloaded the public key corresponding to the RSA key ID. See http://sparewotw.wordpress.com/2012/10/31/how-to-verify-signature-using-sig-file/ for details}}<br />
* Burn the ISO image on a CD or DVD with your preferred software. On Arch, that is covered in [[Optical disc drive#Burning]] <br> {{Note|The quality of optical drives and the discs themselves varies greatly. Generally, using a slow burn speed is recommended for reliable burns. If you are experiencing unexpected behaviour from the disc, try burning at the lowest speed supported by your burner}}<br />
* Or you can write the ISO image to a USB stick. For detailed instructions, see [[USB flash installation media]]<br />
<br />
==== Installing over the network ====<br />
<br />
Instead of writing the boot media to a disc or USB stick, you may alternatively boot the ISO image over the network. This works well when you already have a server set up. Please see the [[PXE]] article for more information, and then continue to [[#Boot the installation medium]].<br />
<br />
==== Install from an existing Linux system ====<br />
<br />
Alternatively, it is possible to install from an already running Linux system. See [[Install from Existing Linux]].<br />
<br />
==== Installing on a virtual machine ====<br />
<br />
Installing on a [[Wikipedia:Virtual machine|virtual machine]] is a good way to become familiar with Arch Linux and its installation procedure without leaving your current operating system and repartitioning the storage drive. It will also let you keep this Beginners' Guide open in your browser throughout the installation. Some users may find it beneficial to have an independent Arch Linux system on a virtual drive, for testing purposes.<br />
<br />
Examples of virtualization software are [[VirtualBox]], [[VMware]], [[QEMU]], [[Xen]], [[Parallels]].<br />
<br />
The exact procedure for preparing a virtual machine depends on the software, but will generally follow these steps:<br />
<br />
# Create the virtual disk image that will host the operating system.<br />
# Properly configure the virtual machine parameters.<br />
# Boot the downloaded ISO image with a virtual CD drive.<br />
# Continue with [[#Boot the installation medium|Boot the installation medium]].<br />
<br />
The following articles may be helpful:<br />
<br />
* [[VirtualBox#Installation steps for Arch Linux guests|Arch Linux as VirtualBox guest]]<br />
* [[Installing Arch Linux from VirtualBox]]<br />
* [[VirtualBox Arch Linux Guest On Physical Drive|Arch Linux as VirtualBox guest on a physical drive]]<br />
* [[Installing Arch Linux in VMware|Arch Linux as VMware guest]]<br />
* [[Moving an existing install into (or out of) a virtual machine]]<br />
<br />
==== Boot the installation medium ====<br />
<br />
Most modern systems allow you to select the boot device during the [[Wikipedia:Power-on self test|POST]] phase, usually by pressing the {{ic|F12}} key while the BIOS splash screen is visible. Select the device which contains the Arch ISO. Alternatively, you may need to change the boot order in your computer's BIOS. <br />
<br />
To do this, press a key (usually {{ic|Delete}}, {{ic|F1}}, {{ic|F2}}, {{ic|F11}} or {{ic|F12}}) during the [[Wikipedia:Power-on self test|POST]] phase. This will take you into the BIOS settings screen where you can set the order in which the system searches for devices to boot from. Set the device which contains the Arch ISO as the first device from which boot is attempted. Select "Save & Exit" (or your BIOS's equivalent) and the computer should then complete its normal boot process.<br />
<br />
When the Arch menu appears, select "Boot Arch Linux" and press {{ic|Enter}} to enter the live environment where you will run the actual installation (if booting from a UEFI boot disk, the option may look more like "Arch Linux archiso x86_64 UEFI").<br />
<br />
===== Testing if you are booted into UEFI mode =====<br />
<br />
In case you have a [[Unified Extensible Firmware Interface|UEFI]] motherboard and UEFI Boot mode is enabled (and is preferred over BIOS/Legacy mode), the CD/USB will automatically launch Arch Linux via [[Gummiboot]] and you will get the following menu (white letters on black background), with the first item highlighted:<br />
{{bc|<br />
Arch Linux archiso x86_64 UEFI USB<br />
UEFI Shell x86_64 v1<br />
UEFI Shell x86_64 v2<br />
EFI Default Loader}}<br />
<br />
If you do not remember which menu you had at boot time, or if you want to make sure you booted into UEFI mode, run:<br />
<br />
# efivar -l<br />
<br />
If ''efivar'' lists the UEFI variables properly, then you have booted in UEFI mode. If not check whether all the requirements listed in [[Unified Extensible Firmware Interface#Requirements for UEFI Variables support to work properly|Unified Extensible Firmware Interface]] are met.<br />
<br />
==== Troubleshooting boot problems ====<br />
<br />
* If you are using an Intel video chipset and the screen goes blank during the boot process, the problem is likely an issue with [[Kernel mode setting]]. A possible workaround may be achieved by rebooting and pressing {{ic|Tab}} over the entry that you are trying to boot (i686 or x86_64). At the end of the string type {{ic|nomodeset}} and press {{ic|Enter}}. Alternatively, try {{ic|1=video=SVIDEO-1:d}} which, if it works, will not disable kernel mode setting. You can also try {{ic|1=i915.modeset=0}}. See the [[Intel]] article for more information.<br />
* If the screen does ''not'' go blank and the boot process gets stuck while trying to load the kernel, press {{ic|Tab}} while hovering over the menu entry, type {{ic|1=acpi=off}} at the end of the string and press {{ic|Enter}}.<br />
<br />
== Installation ==<br />
<br />
You are now presented with a shell prompt, automatically logged in as root. Your shell is [[Zsh]]; this will provide you advanced Tab completion, and other features as part of the [http://grml.org/zsh/ grml config].<br />
For editing text files, the console editor ''nano'' is suggested. If you are not familiar with it, see [[nano#nano usage]].<br />
If you have (or plan on having) a dual boot setup with Windows, see [[Windows and Arch Dual Boot]].<br />
<br />
=== Change the language ===<br />
<br />
{{Tip|These are optional for the majority of users. Useful only if you plan on writing in your own language in any of the configuration files, if you use diacritical marks in the Wi-Fi password, or if you would like to receive system messages (e.g. possible errors) in your own language. Changes here ''only'' affect the installation process.}}<br />
<br />
By default, the keyboard layout is set to {{ic|us}}. If you have a non-[[Wikipedia:File:KB United States-NoAltGr.svg|US]] keyboard layout, run:<br />
<br />
# loadkeys ''layout''<br />
<br />
...where ''layout'' can be {{ic|fr}}, {{ic|uk}}, {{ic|dvorak}}, {{ic|be-latin1}}, etc. See this [[Wikipedia:ISO 3166-1 alpha-2#Officially assigned code elements|wikipedia article]] for a 2-letter country code list. Use the command {{ic|localectl list-keymaps}} to list all available keymaps.<br />
<br />
If some glyphs of your language's alphabet (e.g. accented and non Latin letters) show up as white squares or as other symbols, you may want to change the console font with one from {{ic|/usr/share/kbd/consolefonts/}}. For example:<br />
<br />
# setfont lat9w-16<br />
<br />
You can run the {{ic|showconsolefont}} command to display the full contents of the loaded font. Note that the font name is case-sensitive, so type it ''exactly'' as you see it. See [[Fonts#Console fonts]] for more information.<br />
<br />
By default, the language is set to English (US). If you would like to change the language for the install process ''(German, in this example)'', remove the {{ic|#}} in front of the [[locale]] you want from {{ic|/etc/locale.gen}}, along with English (US). Please choose the {{ic|UTF-8}} entries:<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
en_US.UTF-8 UTF-8<br />
de_DE.UTF-8 UTF-8<br />
}}<br />
<br />
# locale-gen<br />
# export LANG=de_DE.UTF-8<br />
<br />
=== Establish an internet connection ===<br />
<br />
{{Warning|As of [http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id&#61;dee4c244254bb49d1ffa8bd7171ae9cce596d2d0 v197], udev no longer assigns network interface names according to the ''wlanX'' and ''ethX'' naming scheme. If you are coming from a different distribution or are reinstalling Arch and not aware of the new interface naming style, please do not assume that your wireless interface is named ''wlan0'', or that your wired interface is named ''eth0''. You can use the command {{ic|ip link}} to discover the names of your interfaces.}}<br />
<br />
{{Note|Since the ISO released on 2014.04 (but maybe even on previous ones) there seems to be a problem in getting an IP address with DHCP if you are using the family of routers "FritzBox!". At this time models 7390[http://unix.stackexchange.com/questions/126526/archlinux-2014-04-64bit-and-connectivity-problem-during-instalation] and 7112[https://unix.stackexchange.com/questions/126694/enabling-wired-internet-connection-with-dhcp-during-arch-linux-installation/126709] seem to have this issue, but other models may be affected. The issue seems to be between the [[dhcpcd]] client and the FritzBox! routers and the way they assign IP addresses. The solution to the problem seems to be as follows: in your FritzBox! settings, manually delete the entry related to the IP address that identifies your machine. Also, disable the option "Assign always the same IP address to this machine". Now restart the DHCP process or simply reboot your computer and you should get an IP address as usual. If it does not work, try also to reboot your FritzBox!. Once your computer gets the IP address, you can re-enable the previously disabled option. }}<br />
<br />
The {{ic|dhcpcd}} network daemon starts automatically during boot and it will attempt to start a wired connection. Try to ping a server to see if a connection was established. For example, Google's webservers:<br />
<br />
{{hc|# ping -c 3 www.google.com|2=<br />
PING www.l.google.com (74.125.132.105) 56(84) bytes of data.<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=1 ttl=50 time=17.0 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=2 ttl=50 time=18.2 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=3 ttl=50 time=16.6 ms<br />
<br />
--- www.l.google.com ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2003ms<br />
rtt min/avg/max/mdev = 16.660/17.320/18.254/0.678 ms<br />
}}<br />
<br />
If you get a {{ic|ping: unknown host}} error, first check if there is an issue with your cable or wireless signal strength. If not, you will need to set up the network manually, as explained below. Once a connection is established move on to [[#Prepare the storage drive]].<br />
<br />
==== Wired ====<br />
<br />
Follow this procedure if you need to set up a wired connection via a static IP address.<br />
<br />
First, disable the dhcpcd service which was started automatically at boot:<br />
<br />
# systemctl stop dhcpcd.service<br />
<br />
Identify the name of your Ethernet interface.<br />
<br />
{{hc|# ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp2s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000<br />
link/ether 00:11:25:31:69:20 brd ff:ff:ff:ff:ff:ff<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000<br />
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
In this example, the Ethernet interface is {{ic|enp2s0f0}}. If you are unsure, your Ethernet interface is likely to start with the letter "e", and unlikely to be "lo" or start with the letter "w".<br />
<br />
You also need to know these settings:<br />
<br />
* Static IP address.<br />
* Subnet mask.<br />
* Gateway's IP address.<br />
* Name servers' (DNS) IP addresses.<br />
* Domain name (unless you are on a local LAN, in which case you can make it up).<br />
<br />
Activate the connected Ethernet interface (e.g. {{ic|enp2s0f0}}):<br />
<br />
# ip link set enp2s0f0 up<br />
<br />
Add the address:<br />
<br />
# ip addr add ''ip_address''/''mask_bits'' dev ''interface_name''<br />
<br />
For example:<br />
<br />
# ip addr add 192.168.1.2/24 dev enp2s0f0<br />
<br />
For more options, run {{ic|man ip}}.<br />
<br />
Add your gateway like this, substituting your own gateway's IP address:<br />
<br />
# ip route add default via ''ip_address''<br />
<br />
For example:<br />
<br />
# ip route add default via 192.168.1.1<br />
<br />
Edit {{ic|resolv.conf}}, substituting your name servers' IP addresses and your local domain name:<br />
<br />
{{hc|# nano /etc/resolv.conf|<br />
nameserver 61.23.173.5<br />
nameserver 61.95.849.8<br />
search example.com<br />
}}<br />
<br />
{{Note|Currently, you may include a maximum of three {{ic|nameserver}} lines. In order to overcome this limitation, you can use a locally caching nameserver like [[dnsmasq]].}}<br />
<br />
You should now have a working network connection. If you do not, check the detailed [[Network configuration]] page.<br />
<br />
==== Wireless ====<br />
<br />
Follow this procedure if you need wireless connectivity (Wi-Fi) during the installation process.<br />
<br />
First, identify the name of your wireless interface:<br />
<br />
{{hc|# iw dev|2=<br />
phy#0<br />
Interface wlp3s0<br />
ifindex 3<br />
wdev 0x1<br />
addr 00:11:22:33:44:55<br />
type managed<br />
}}<br />
<br />
In this example, {{ic|wlp3s0}} is the available wireless interface. If you are unsure, your wireless interface is likely to start with the letter "w", and unlikely to be "lo" or start with the letter "e". <br />
<br />
{{Note|If you do not see output similar to this, then your wireless driver has not been loaded. If this is the case, you must load the driver yourself. Please see [[Wireless network configuration]] for more detailed information.}}<br />
<br />
Now use [[netctl]]'s {{ic|wifi-menu}} to connect to a network:<br />
<br />
# wifi-menu wlp3s0<br />
<br />
You should now have a working network connection. If you do not, try [[#Without wifi-menu]] or check the detailed [[Wireless network configuration]] page.<br />
<br />
===== Without wifi-menu =====<br />
<br />
Bring the interface up with:<br />
<br />
# ip link set wlp3s0 up<br />
<br />
To verify that the interface is up, inspect the output of the following command:<br />
<br />
{{hc|# ip link show wlp3s0|<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000<br />
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
The {{ic|UP}} in {{ic|<BROADCAST,MULTICAST,UP,LOWER_UP>}} is what indicates the interface is up, not the later {{ic|state DOWN}}.<br />
<br />
Most wireless chipsets require firmware in addition to a corresponding driver. The kernel tries to identify and load both automatically. If you get output like {{ic|SIOCSIFFLAGS: No such file or directory}}, this means you will need to manually load the firmware. If unsure, invoke {{ic|dmesg}} to query the kernel log for a firmware request from the wireless chipset. For example, if you have an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
<br />
{{hc|<nowiki># dmesg | grep firmware</nowiki>|<br />
firmware: requesting iwlwifi-5000-1.ucode<br />
}}<br />
<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
{{Warning|Wireless chipset firmware packages (for cards which require them) are pre-installed under {{ic|/usr/lib/firmware}} in the live environment (on CD/USB stick) '''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!''' Package installation is covered later in this guide. Ensure installation of both your wireless module and firmware before rebooting! See [[Wireless network configuration]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset.}}<br />
<br />
Next, scan for available networks using {{ic|iw dev wlp3s0 scan <nowiki>|</nowiki> grep SSID}}, then connect to a network with:<br />
<br />
# wpa_supplicant -B -i wlp3s0 -c <(wpa_passphrase "''ssid''" "''psk''")<br />
<br />
You need to replace ''ssid'' with the name of your network (e.g. "Linksys etc...") and ''psk'' with your wireless password, '''leaving the quotes around the network name and password'''.<br />
<br />
Finally, you have to give your interface an IP address. This can be set manually or using dhcp:<br />
<br />
# dhcpcd wlp3s0<br />
<br />
If that does not work, issue the following commands:<br />
<br />
# echo 'ctrl_interface=DIR=/run/wpa_supplicant' > /etc/wpa_supplicant.conf<br />
# wpa_passphrase ''ssid'' ''passphrase'' >> /etc/wpa_supplicant.conf<br />
# ip link set ''interface'' up<br />
# wpa_supplicant -B -D nl80211 -c /etc/wpa_supplicant.conf -i ''interface''<br />
# dhcpcd -A ''interface''<br />
<br />
Setting the interface up at step 3 may not be needed, but does no harm in any case.<br />
<br />
If ''wpa_supplicant'' complains about an unsupported driver at step 4, just leave out the {{ic|-D nl80211}} parameter:<br />
<br />
# wpa_supplicant -B -c /etc/wpa_supplicant.conf -i ''interface''<br />
<br />
==== Analog modem, ISDN, or PPPoE DSL ====<br />
<br />
For xDSL, dial-up, and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
==== Behind a proxy server ====<br />
<br />
If you are behind a proxy server, you will need to export the {{ic|http_proxy}} and {{ic|ftp_proxy}} environment variables. See [[Proxy settings]] for more information.<br />
<br />
=== Prepare the storage drive ===<br />
<br />
{{Warning|Partitioning can destroy data. You are '''strongly''' cautioned and advised to backup any critical data before proceeding.}}<br />
{{Note|If you are installing to a USB flash key, see [[Installing Arch Linux on a USB key]].}}<br />
{{Tip|If you want to create any stacked block devices for [[LVM]], [[disk encryption]] or [[RAID]], do it now.}}<br />
<br />
==== Choose a partition table type ====<br />
<br />
{{Note|If Arch and Windows are dual-booting from same disk, then Arch '''should''' follow the same firmware boot mode and partitioning combination used by the installed Windows in the disk. Otherwise Windows will fail to boot. See [[Windows and Arch Dual Boot#Important information]] for details.}}<br />
<br />
You have to choose between [[GUID Partition Table]] (GPT) and [[Master Boot Record]] (MBR), see also [[Partitioning#Choosing between GPT and MBR]].<br />
<br />
* It is recommended to always use GPT for UEFI boot, as some UEFI firmwares do not allow UEFI-MBR boot.<br />
* Some BIOS systems may have issues with GPT. See http://mjg59.dreamwidth.org/8035.html and http://rodsbooks.com/gdisk/bios.html for more info and possible workarounds.<br />
<br />
==== Partitioning tool ====<br />
<br />
Absolute beginners are encouraged to use a graphical partitioning tool. [[GParted]] is a good example, and is [http://gparted.sourceforge.net/livecd.php provided as a live CD]. A drive should first be [[partitioning|partitioned]] and afterwards the partitions should be formatted with a [[File systems|file system]].<br />
<br />
While ''gparted'' may be easier to use, if you just want to create a few partitions on a new disk you can get the job done quickly by just using one of the [[Partitioning#Partitioning tools|fdisk variants]] which are included on the install medium. In the next section short usage instructions for both [[Partitioning#Gdisk usage summary|gdisk]] and [[Partitioning#Fdisk usage summary|fdisk]] follow.<br />
<br />
==== Erase partition table ====<br />
<br />
If you want to start from scratch, and do not intend to keep existing partitions, erase the partition table with the following command. This simplifies creating new partitions and avoids problems with converting disks from MBR to GPT and vice versa.<br />
<br />
# sgdisk --zap-all /dev/sda<br />
<br />
==== Partition scheme ====<br />
<br />
You can decide into how many partitions the disk should be split, and for which directory each partition should be used in the system. The mapping from partitions to directories (frequently called 'mount points') is the [[Partitioning#Partition scheme|Partition scheme]]. The simplest, and not a bad choice, is to make just one huge {{ic|/}} partition. Another popular choice is to have a {{ic|/}} and a {{ic|/home}} partition.<br />
<br />
'''Additional required partitions:'''<br />
* If you have a [[Unified Extensible Firmware Interface|UEFI]] motherboard, you will need to create an extra [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]].<br />
* If you have a BIOS motherboard (or plan on booting in BIOS compatibility mode) and you want to setup GRUB on a GPT-partitioned drive, you will need to create an extra [[GRUB#GUID Partition Table (GPT) specific instructions|BIOS Boot Partition]] of size 1 or 2 MiB and {{ic|EF02}} type code. Syslinux does not need one.<br />
* If you have a requirement for a [[Disk encryption]] of the system itself, this must be reflected in your partition scheme. It is unproblematic to add encrypted folders, containers or home directories after the system is installed.<br />
<br />
See [[Swap]] for details if you wish to set up a swap partition or swap file. A swap file is easier to resize than a partition and can be created at any point after installation, but cannot be used with a Btrfs filesystem.<br />
<br />
If you have already created your partitions, proceed to [[#Create filesystems]]. Otherwise, see the following example.<br />
<br />
==== Example ====<br />
<br />
The Arch Linux install media includes the following partitioning tools: {{ic|fdisk}}, {{ic|gdisk}}, {{ic|cfdisk}}, {{ic|cgdisk}} and {{ic|parted}}.<br />
<br />
{{Tip|Use the {{ic|lsblk}} command to list the hard disks attached to your system, along with the sizes of their existing partitions. This will help you to be confident you are partitioning the right disk. {{ic|lsblk -f}} will show additional information about Labels, UUIDs and filesystem types.}}<br />
<br />
The example system will contain a 15 GB root partition, and a [[Partitioning#/home|home]] partition for the remaining space. Choose either MBR or GPT, as described above. Do not choose both!<br />
<br />
It should be emphasized that partitioning is a personal choice and that this example is only for illustrative purposes. See [[Partitioning]].<br />
<br />
===== Using cgdisk to create GPT partitions =====<br />
<br />
Launch ''cgdisk'' with:<br />
<br />
# cgdisk /dev/sda<br />
<br />
{{Tip|If cgdisk cannot change your disk to GPT, {{pkg|parted}} can.}}<br />
<br />
'''Root:'''<br />
* Choose ''New'' (or press {{ic|N}}) – {{ic|Enter}} for the first sector (2048) – type in {{ic|15G}} – {{ic|Enter}} for the default hex code (8300) – {{ic|Enter}} for a blank partition name.<br />
<br />
'''Home:'''<br />
* Press the down arrow a couple of times to move to the larger free space area.<br />
* Choose ''New'' (or press {{ic|N}}) – {{ic|Enter}} for the first sector – {{ic|Enter}} to use the rest of the drive (or you could type in the desired size; for example {{ic|30G}}) – {{ic|Enter}} for the default hex code (8300) – {{ic|Enter}} for a blank partition name.<br />
<br />
Here is what it should look like:<br />
<br />
Part. # Size Partition Type Partition Name<br />
----------------------------------------------------------------<br />
1007.0 KiB free space<br />
1 15.0 GiB Linux filesystem<br />
2 123.45 GiB Linux filesystem<br />
<br />
Double check and make sure that you are happy with the partition sizes as well as the partition table layout before continuing.<br />
<br />
If you would like to start over, you can simply select ''Quit'' (or press {{ic|Q}}) to exit without saving changes and then restart ''cgdisk''.<br />
<br />
If you are satisfied, choose ''Write'' (or press {{ic|Shift+W}}) to finalize and to write the partition table to the drive. Type {{ic|yes}} and choose ''Quit'' (or press {{ic|Q}}) to exit without making any more changes.<br />
<br />
===== Using fdisk to create MBR partitions =====<br />
<br />
{{Note|There is also ''cfdisk'', which is similar in UI to ''cgdisk'', but it currently does not automatically align the first partition properly. That is why the classic ''fdisk'' tool is used here.}}<br />
<br />
Launch ''fdisk'' with:<br />
<br />
# fdisk /dev/sda<br />
<br />
Create the partition table:<br />
<br />
* {{ic|Command (m for help):}} type {{ic|o}} and press {{ic|Enter}}<br />
<br />
Then create the first partition:<br />
<br />
# {{ic|Command (m for help):}} type {{ic|n}} and press {{ic|Enter}}<br />
# Partition type: {{ic|Select (default p):}} press {{ic|Enter}}<br />
# {{ic|Partition number (1-4, default 1):}} press {{ic|Enter}}<br />
# {{ic|First sector (2048-209715199, default 2048):}} press {{ic|Enter}}<br />
# {{ic|Last sector, +sectors or +size{K,M,G,T,P} (2048-209715199....., default 209715199):}} type {{ic|+15G}} and press {{ic|Enter}}<br />
<br />
Then create a second partition:<br />
<br />
# {{ic|Command (m for help):}} type {{ic|n}} and press {{ic|Enter}}<br />
# Partition type: {{ic|Select (default p):}} press {{ic|Enter}}<br />
# {{ic|Partition number (1-4, default 2):}} press {{ic|Enter}}<br />
# {{ic|First sector (31459328-209715199, default 31459328):}} press {{ic|Enter}}<br />
# {{ic|Last sector, +sectors or +size{K,M,G,T,P} (31459328-209715199....., default 209715199):}} press {{ic|Enter}}<br />
<br />
Now preview the new partition table:<br />
<br />
* {{ic|Command (m for help):}} type {{ic|p}} and press {{ic|Enter}}<br />
<br />
{{bc|<br />
Disk /dev/sda: 107.4 GB, 107374182400 bytes, 209715200 sectors<br />
Units &#61; sectors of 1 * 512 &#61; 512 bytes<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
I/O size (minimum/optimal): 512 bytes / 512 bytes<br />
Disk identifier: 0x5698d902<br />
<br />
Device Boot Start End Blocks Id System<br />
/dev/sda1 2048 31459327 15728640 83 Linux<br />
/dev/sda2 31459328 209715199 89127936 83 Linux<br />
}}<br />
<br />
Then write the changes to disk:<br />
<br />
* {{ic|Command (m for help):}} type {{ic|w}} and press {{ic|Enter}}<br />
<br />
If everything went well fdisk will now quit with the following message:<br />
<br />
{{bc|<br />
The partition table has been altered!<br />
<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks. <br />
}}<br />
<br />
In case this does not work because ''fdisk'' encountered an error, you can use the {{ic|q}} command to exit.<br />
<br />
==== Create filesystems ====<br />
<br />
Simply partitioning is not enough; the partitions also need a [[File systems|filesystem]]. To format the partitions with an ext4 filesystem:<br />
<br />
{{Warning|Double check and triple check that it is actually {{ic|/dev/sda1}} and {{ic|/dev/sda2}} that you want to format. You can use {{ic|lsblk}} to help with this.}}<br />
<br />
# mkfs.ext4 /dev/sda1<br />
# mkfs.ext4 /dev/sda2<br />
<br />
If you have made a partition dedicated to swap (code 82), do not forget to format and activate it with:<br />
<br />
# mkswap /dev/sda''X''<br />
# swapon /dev/sda''X''<br />
<br />
For UEFI, you should format the EFI System Partition (for example /dev/sd''XY'') with:<br />
<br />
# mkfs.fat -F32 /dev/sd''XY''<br />
<br />
=== Mount the partitions ===<br />
<br />
Each partition is identified with a number suffix. For example, {{ic|sda1}} specifies the first partition of the first drive, while {{ic|sda}} designates the entire drive.<br />
<br />
To display the current partition layout:<br />
<br />
# lsblk -f<br />
<br />
{{Note|Do not mount more than one partition to the same directory. And pay attention, because the mounting order is important.}}<br />
<br />
First, mount the root partition on {{ic|/mnt}}. Following the example above (yours may be different), it would be:<br />
<br />
# mount /dev/sda1 /mnt<br />
<br />
Then mount the home partition and any other separate partition ({{ic|/boot}}, {{ic|/var}}, etc), if you have any:<br />
<br />
# mkdir /mnt/home<br />
# mount /dev/sda2 /mnt/home<br />
<br />
In case you have a UEFI motherboard, mount the EFI System Partition to {{ic|/boot}}. Whilst other mountpoints are viable, using {{ic|/boot}} is recommended as explained in the [[EFISTUB]] article.<br />
<br />
# mkdir /mnt/boot<br />
# mount /dev/sd''XY'' /mnt/boot<br />
<br />
=== Select a mirror ===<br />
<br />
You may want to edit the {{ic|mirrorlist}} file and place your preferred mirror first. A copy of this file will be installed on your new system by {{ic|pacstrap}} as well, so it is worth getting it right.<br />
<br />
{{hc|# nano /etc/pacman.d/mirrorlist|<br />
##<br />
## Arch Linux repository mirrorlist<br />
## Sorted by mirror score from mirror status page<br />
## Generated on 2012-MM-DD<br />
##<br />
<br />
<nowiki>Server = http://mirror.example.xyz/archlinux/$repo/os/$arch</nowiki><br />
...}}<br />
<br />
If you want, you can make it the ''only'' mirror available by deleting all other lines, but it is usually a good idea to have a few more, in case the first one goes offline.<br />
<br />
{{Tip|<br />
* Use the [https://www.archlinux.org/mirrorlist/ Mirrorlist Generator] to get an updated list for your country. HTTP mirrors are faster than FTP, because of something called [[Wikipedia:Keepalive|keepalive]]. With FTP, ''pacman'' has to send out a signal each time it downloads a package, resulting in a brief pause. For other ways to generate a mirror list, see [[Mirrors#Sorting mirrors|Sorting mirrors]] and [[Reflector]].<br />
* [https://archlinux.org/mirrors/status/ Arch Linux MirrorStatus] reports various aspects about the mirrors such as network problems with mirrors, data collection problems, the last time mirrors have been synced, etc.<br />
}}<br />
<br />
{{Note|<br />
* Whenever in the future you change your mirrorlist, refresh all package lists with {{ic|pacman -Syy}}, to ensure that the package lists are updated consistently. See [[Mirrors]] for more information.<br />
* If you are using an older installation medium, your mirrorlist might be outdated, which might lead to problems when updating Arch Linux (see {{Bug|22510}}). Therefore it is advised to obtain the latest mirror information as described above.<br />
* Some issues have been reported in the [https://bbs.archlinux.org/ Arch Linux forums] regarding network problems that prevent ''pacman'' from updating/synchronizing repositories (see [https://bbs.archlinux.org/viewtopic.php?id&#61;68944] and [https://bbs.archlinux.org/viewtopic.php?id&#61;65728]). When installing Arch Linux natively, these issues have been resolved by replacing the default ''pacman'' file downloader with an alternative (see [[Improve pacman performance]] for more details). When installing Arch Linux as a guest OS in [[VirtualBox]], this issue has also been addressed by using "Host interface" instead of "NAT" in the machine properties.<br />
}}<br />
<br />
=== Install the base system ===<br />
<br />
The base system is installed using the ''pacstrap'' script. The {{ic|-i}} switch can be omitted if you wish to install every package from the {{Grp|base}} group without prompting. You may also want to include {{Grp|base-devel}}, as you will need these packages should you want to build packages from the [[AUR]] or using the [[ABS]]:<br />
<br />
# pacstrap -i /mnt base base-devel<br />
<br />
{{Note|<br />
* If ''pacstrap'' hangs with {{ic|error: failed retrieving file 'core.db' from mirror... : Connection time-out}}, yet your mirrors are configured correctly, try setting a different [[Resolv.conf|name server]].<br />
* If in the middle of the installation of base packages you get a request to import a PGP key, agree to download the key to proceed. This is likely to happen if the Arch ISO you are using is out of date.<br />
* If ''pacman'' fails to verify your packages, stop the process with {{ic|Ctrl+C}} and check the system time with {{ic|cal}}. If the system date is invalid (e.g. it shows the year 2010), signing keys will be considered expired (or invalid), signature checks on packages will fail and installation will be interrupted. Make sure to correct the system time, using the command {{ic|ntpd -qg}}, and retry running the ''pacstrap'' command. Refer to [[Time]] page for more information on correcting system time.<br />
* If ''pacman'' complains that {{ic|error: failed to commit transaction (invalid or corrupted package)}}, run the following command:<br />
# pacman-key --init && pacman-key --populate archlinux<br />
}}<br />
<br />
This will give you a basic Arch system. Other packages can be installed later using [[pacman]].<br />
<br />
=== Generate an fstab ===<br />
<br />
Generate an [[fstab]] file with the following command. UUIDs will be used because they have certain advantages (see [[fstab#Identifying filesystems]]). If you would prefer to use labels instead, replace the {{ic|-U}} option with {{ic|-L}}:<br />
<br />
# genfstab -U -p /mnt >> /mnt/etc/fstab<br />
# nano /mnt/etc/fstab<br />
<br />
{{Warning|The {{ic|fstab}} file should always be checked after generating it. If you encounter errors running ''genfstab'' or later in the install process, do '''not''' run ''genfstab'' again; just edit the {{ic|fstab}} file.}}<br />
<br />
A few considerations:<br />
<br />
* The last field determines the order in which partitions are checked at start up: use {{ic|1}} for the (non-Btrfs) root partition, which should be checked first; {{ic|2}} for all other partitions you want checked at start up; and {{ic|0}} means 'do not check' (see [[fstab#Field definitions]]).<br />
* All [[Btrfs]] partitions should have {{ic|0}} for this field. Normally, you will also want your ''swap'' partition to have {{ic|0}}.<br />
<br />
=== Chroot and configure the base system ===<br />
<br />
Next, [[Change Root|chroot]] into your newly installed system:<br />
<br />
# arch-chroot /mnt /bin/bash<br />
<br />
{{Note|Leave out {{ic|/bin/bash}} to chroot into the sh shell.}}<br />
<br />
At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system. These can either be created if they do not exist, or edited if you wish to change the defaults.<br />
<br />
Closely following and understanding these steps is of key importance to ensure a properly configured system.<br />
<br />
==== Locale ====<br />
<br />
Locales are used by {{Pkg|glibc}} and other locale-aware programs or libraries for rendering text, correctly displaying regional monetary values, time and date formats, alphabetic idiosyncrasies, and other locale-specific standards. There are two files that need editing: {{ic|locale.gen}} and {{ic|locale.conf}}.<br />
<br />
The {{ic|locale.gen}} file has everything commented out by default. To uncomment a line remove the {{ic|#}} in the front. Using {{ic|UTF-8}} is highly recommended over {{ic|ISO-8859}}:<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
...<br />
#en_SG ISO-8859-1<br />
en_US.UTF-8 UTF-8<br />
#en_US ISO-8859-1<br />
...<br />
}}<br />
<br />
Generate the locale(s) specified in {{ic|/etc/locale.gen}}:<br />
<br />
# locale-gen<br />
<br />
{{Note|This will also run with every update of {{Pkg|glibc}}.}}<br />
<br />
Create the {{ic|/etc/locale.conf}} file substituting your chosen locale:<br />
<br />
# echo LANG=en_US.UTF-8 > /etc/locale.conf<br />
<br />
{{Note|<br />
* The locale specified in the {{ic|LANG}} variable must be uncommented in {{ic|/etc/locale.gen}}.<br />
* The {{ic|locale.conf}} file does not exist by default. Setting only {{ic|LANG}} should be enough as it will act as the default value for all other variables.<br />
}}<br />
<br />
Export substituting your chosen locale:<br />
<br />
# export LANG=en_US.UTF-8<br />
<br />
{{Tip|To use other locales for other {{ic|LC_*}} variables, run {{ic|locale}} to see the available options and add them to {{ic|locale.conf}}. It is not recommended to set the {{ic|LC_ALL}} variable. See [[Locale#Setting the locale system-wide]] for details.}}<br />
<br />
==== Console font and keymap ====<br />
<br />
If you changed the default console keymap and font in [[#Change the language]], you will have to edit {{ic|/etc/vconsole.conf}} ''accordingly'' (create it if it does not exist) to make those changes persist in the installed system, for example:<br />
<br />
{{hc|# nano /etc/vconsole.conf|2=<br />
KEYMAP=de-latin1<br />
FONT=lat9w-16<br />
}}<br />
<br />
{{Warning|If you set {{ic|KEYMAP}} to a different value than the one you initially set with ''loadkeys'', and then you [[#Set the root password]], you may have problems logging into the new system after rebooting, because some keys may be mapped differently between the two layouts.}}<br />
<br />
Note that these settings are only valid for your virtual consoles, not in [[Xorg]]. See [[Fonts#Console fonts]] for more information.<br />
<br />
==== Time zone ====<br />
<br />
Available time zones and subzones can be found in the {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}} directories.<br />
<br />
To view the available zones, check the directory {{ic|/usr/share/zoneinfo/}}:<br />
<br />
# ls /usr/share/zoneinfo/<br />
<br />
Similarly, you can check the contents of directories belonging to a subzone:<br />
<br />
# ls /usr/share/zoneinfo/Europe<br />
<br />
Create a symbolic link {{ic|/etc/localtime}} to your subzone file {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}} using this command:<br />
<br />
# ln -s /usr/share/zoneinfo/''Zone''/''SubZone'' /etc/localtime<br />
<br />
'''Example:'''<br />
<br />
# ln -s /usr/share/zoneinfo/Europe/Minsk /etc/localtime<br />
<br />
{{Note|If you get {{ic|ln: failed to create symbolic link '/etc/localtime': File exists}}, check the existing file with {{ic|ls -l /etc/localtime}} and add the {{ic|-f}} option to the ''ln'' command to overwrite it.}}<br />
<br />
==== Hardware clock ====<br />
<br />
Set the hardware clock mode uniformly between your operating systems. Otherwise, they may overwrite the hardware clock and cause time shifts.<br />
<br />
You can generate {{ic|/etc/adjtime}} automatically by using one of the following commands:<br />
<br />
* '''UTC''' (recommended): {{Note|Using [[Wikipedia:Coordinated Universal Time|UTC]] for the hardware clock does not mean that software will display time in UTC.}} {{bc|# hwclock --systohc --utc}}<br />
* '''localtime''' (discouraged; used by default in Windows): {{Warning|Using ''localtime'' may lead to several known and unfixable bugs. However, there are no plans to drop support for ''localtime''.}} {{bc|# hwclock --systohc --localtime}}<br />
<br />
==== Kernel modules ====<br />
<br />
{{Tip|This is just an example, you do not need to set it. All needed modules are automatically loaded by udev, so you will rarely need to add something here. Only add modules that you know are missing.}}<br />
<br />
For kernel modules to load during boot, place a {{ic|*.conf}} file in {{ic|/etc/modules-load.d/}}, with a name based on the program that uses them:<br />
<br />
{{hc|# nano /etc/modules-load.d/virtio-net.conf|<br />
# Load 'virtio-net.ko' at boot.<br />
<br />
virtio-net<br />
}}<br />
<br />
If there are more modules to load per {{ic|*.conf}}, the module names can be separated by newlines. A good example are the [[VirtualBox#Installation steps for Arch Linux guests|VirtualBox Guest Additions]].<br />
<br />
Empty lines and lines starting with {{ic|#}} or {{ic|;}} are ignored.<br />
<br />
==== Hostname ====<br />
<br />
Set the [[Wikipedia:Hostname|hostname]] to your liking (e.g. ''arch''):<br />
<br />
# echo ''myhostname'' > /etc/hostname<br />
<br />
Add the same hostname to {{ic|/etc/hosts}}:<br />
<br />
{{hc|# nano /etc/hosts|<br />
#<br />
# /etc/hosts: static lookup table for host names<br />
#<br />
<br />
#<ip-address> <hostname.domain.org> <hostname><br />
127.0.0.1 localhost.localdomain localhost ''myhostname''<br />
::1 localhost.localdomain localhost<br />
<br />
# End of file<br />
}}<br />
<br />
=== Configure the network ===<br />
<br />
You need to configure the network again, but this time for your newly installed environment. The procedure and prerequisites are very similar to the one described [[#Establish an internet connection|above]], except we are going to make it persistent and automatically run at boot.<br />
<br />
As a first step, identify the network interface name you want to configure the connection for with {{ic|ip link}}. <br />
<br />
{{Note|<br />
* For more in-depth information on network configration, visit [[Network configuration]] and [[Wireless network configuration]].<br />
* If you would like to use the old interface naming scheme (ie. eth* and wlan*) you can accomplish this by creating an empty file at {{ic|/etc/udev/rules.d/80-net-setup-link.rules}} which will mask the file of the same name located under {{ic|/usr/lib/udev/rules.d}}.<br />
}}<br />
<br />
==== Wired ====<br />
<br />
===== Dynamic IP =====<br />
<br />
; Using dhcpcd<br />
<br />
If you only use a single fixed wired network connection, you do not need a network management service and can simply enable the {{ic|dhcpcd}} service for the interface:<br />
<br />
# systemctl enable dhcpcd@''interface_name''.service<br />
<br />
; Using netctl<br />
<br />
Copy a sample profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/ethernet-dhcp my_network<br />
<br />
Edit the profile as needed (update {{ic|Interface}} from {{ic|eth0}} to the interface name of the system. <br />
# nano my_network<br />
<br />
Enable the {{ic|my_network}} profile:<br />
<br />
# netctl enable my_network<br />
<br />
{{Note|You will get the message "Running in chroot, ignoring request.". This can be ignored for now.}}<br />
<br />
; Using netctl-ifplugd<br />
<br />
{{Warning|You cannot use this method in conjunction with explicitly enabling profiles, such as {{ic|netctl enable ''profile''}}.}}<br />
<br />
Alternatively, you can use {{ic|netctl-ifplugd}}, which gracefully handles dynamic connections to new networks.<br />
<br />
Install {{Pkg|ifplugd}}, which is required for {{ic|netctl-ifplugd}}:<br />
<br />
# pacman -S ifplugd<br />
<br />
Then enable for interface that you want:<br />
<br />
# systemctl enable netctl-ifplugd@''interface''.service<br />
<br />
{{Tip|[[netctl]] also provides {{ic|netctl-auto}}, which can be used to handle wired profiles in conjunction with {{ic|netctl-ifplugd}}.}}<br />
<br />
===== Static IP =====<br />
<br />
; Using netctl<br />
<br />
Copy a sample profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/ethernet-static my_network<br />
<br />
Edit the profile as needed (modify {{ic|Interface}}, {{ic|Address}}, {{ic|Gateway}} and {{ic|DNS}}):<br />
<br />
# nano my_network<br />
<br />
Notice the {{ic|/24}} in {{ic|Address}} which is the [[wikipedia:Classless Inter-Domain Routing#CIDR notation|CIDR notation]] of a {{ic|255.255.255.0}} netmask.<br />
<br />
Enable above created profile to start it at every boot:<br />
<br />
# netctl enable my_network<br />
<br />
; Using systemd-networkd<br />
<br />
See [[systemd-networkd]].<br />
<br />
==== Wireless ====<br />
<br />
{{Note|If your wireless adapter requires a firmware (as described in the above [[#Wireless|Establish an internet connection]] section and also in the article [[Wireless network configuration#Device driver]]), install the package containing your firmware. Most of the time, the {{Pkg|linux-firmware}} package will contain the needed firmware. Though for some devices, the required firmware might be in its own package. For example:<br />
{{bc|# pacman -S zd1211-firmware}}<br />
See [[Wireless network configuration#Installing driver/firmware]] for more info.}}<br />
<br />
Install {{Pkg|iw}} and {{Pkg|wpa_supplicant}} which you will need to connect to a network:<br />
<br />
# pacman -S iw wpa_supplicant<br />
<br />
===== Adding wireless networks =====<br />
<br />
; Using wifi-menu<br />
<br />
Install {{Pkg|dialog}}, which is required for {{ic|wifi-menu}}:<br />
<br />
# pacman -S dialog<br />
<br />
After finishing the rest of this installation and rebooting, you can connect to the network with {{ic|wifi-menu ''interface_name''}} (where {{ic|''interface_name''}} is the interface of your wireless chipset).<br />
<br />
# wifi-menu ''interface_name''<br />
<br />
{{Warning|This must be done '''after''' your reboot when you are no longer chrooted. The process spawned by this command will conflict with the one you have running outside of the chroot. Alternatively, you could just configure a network profile manually using the following templates so that you do not have to worry about using {{ic|wifi-menu}} at all.}}<br />
<br />
; Using manual netctl profiles<br />
<br />
Copy a network profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/wireless-wpa my-network<br />
<br />
Edit the profile as needed (modify {{ic|Interface}}, {{ic|ESSID}} and {{ic|Key}}):<br />
<br />
# nano my-network<br />
<br />
Enable above created profile to start it at every boot:<br />
<br />
# netctl enable my-network<br />
<br />
===== Connect automatically to known networks =====<br />
<br />
{{Warning|You cannot use this method in conjunction with explicitly enabling profiles, such as {{ic|netctl enable ''profile''}}.}}<br />
<br />
Install {{Pkg|wpa_actiond}}, which is required for {{ic|netctl-auto}}:<br />
<br />
# pacman -S wpa_actiond<br />
<br />
Enable the {{ic|netctl-auto}} service, which will connect to known networks and gracefully handle roaming and disconnects:<br />
<br />
# systemctl enable netctl-auto@''interface_name''.service<br />
<br />
{{Tip|[[netctl]] also provides {{ic|netctl-ifplugd}}, which can be used to handle wired profiles in conjunction with {{ic|netctl-auto}}.}}<br />
<br />
==== Analog modem, ISDN or PPPoE DSL ====<br />
<br />
For xDSL, dial-up and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Create an initial ramdisk environment ===<br />
<br />
{{Tip|Most users can skip this step and use the defaults provided in {{ic|mkinitcpio.conf}}. The initramfs image (from the {{ic|/boot}} folder) has already been generated based on this file when the {{Pkg|linux}} package (the Linux kernel) was installed earlier with ''pacstrap''.}}<br />
<br />
Here you need to set the right [[Mkinitcpio#HOOKS|hooks]] if the root is on a USB drive, if you use RAID, LVM, if using a multi-device Btrfs volumes as root, or if {{ic|/usr}} is on a separate partition.<br />
<br />
Edit {{ic|/etc/mkinitcpio.conf}} as needed and re-generate the initramfs image with:<br />
<br />
# mkinitcpio -p linux<br />
<br />
{{Note|Arch VPS installations on QEMU (e.g. when using {{ic|virt-manager}}) may need {{ic|virtio}} modules in {{ic|mkinitcpio.conf}} to be able to boot.<br />
{{hc|# nano /etc/mkinitcpio.conf|2=<br />
MODULES="virtio virtio_blk virtio_pci virtio_net"<br />
}}<br />
}}<br />
<br />
=== Set the root password ===<br />
<br />
Set the root password with:<br />
<br />
# passwd<br />
<br />
=== Install and configure a bootloader ===<br />
<br />
==== For BIOS motherboards ====<br />
<br />
For BIOS systems, several boot loaders are available, see [[Boot loaders]] for a complete list. Choose one as per your convenience. Here, two of the possibilities are given as examples:<br />
<br />
* [[Syslinux]] is (currently) limited to loading only files from the partition where it was installed. Its configuration file is considered to be easier to understand. An example configuration can be found in the [[Syslinux#Examples|syslinux]] article.<br />
* [[GRUB]] is more feature-rich and supports more complex scenarios. Its configuration file(s) is more similar to 'sh' scripting language, which may be difficult for beginners to manually write. It is recommended that they automatically generate one.<br />
<br />
===== Syslinux =====<br />
<br />
If you opted for a GUID partition table (GPT) for your hard drive earlier, you need to install the {{Pkg|gptfdisk}} package now for the installation of ''syslinux'' to work:<br />
<br />
# pacman -S gptfdisk<br />
<br />
Install the {{Pkg|syslinux}} package and then use the {{ic|syslinux-install_update}} script to automatically ''install'' the bootloader ({{ic|-i}}), mark the partition ''active'' by setting the boot flag ({{ic|-a}}), and install the ''MBR'' boot code ({{ic|-m}}):<br />
<br />
# pacman -S syslinux<br />
# syslinux-install_update -iam<br />
<br />
After installing Syslinux, configure {{ic|syslinux.cfg}} to point to the right root partition. This step is vital. If it points to the wrong partition, Arch Linux will not boot. Change {{ic|/dev/sda3}} to reflect your root partition (if you partitioned your drive as in [[#Prepare the storage drive|the example]], your root partition is {{ic|/dev/sda1}}).<br />
<br />
{{hc|# nano /boot/syslinux/syslinux.cfg|2=<br />
...<br />
LABEL arch<br />
...<br />
APPEND root='''/dev/sda3''' rw<br />
...<br />
}}<br />
<br />
If adding [[UUID]] rather than partition number the syntax is {{ic|1=APPEND root=UUID=''partition_uuid'' rw}}.<br />
<br />
Do the same for the fallback entry.<br />
<br />
For more information on configuring and using Syslinux, see [[Syslinux]].<br />
<br />
===== GRUB =====<br />
<br />
Install the {{Pkg|grub}} package and then run {{ic|grub-install}} to install the bootloader:<br />
<br />
# pacman -S grub<br />
# grub-install --target=i386-pc --recheck '''/dev/sda'''<br />
<br />
{{Note|<br />
* Change {{ic|/dev/sda}} to reflect the drive you installed Arch on. Do not append a partition number (do not use {{ic|sda''X''}}).<br />
* For GPT-partitioned drives on BIOS motherboards, you also need a "BIOS Boot Partition". See [[GRUB#GUID Partition Table (GPT) specific instructions|GPT-specific instructions]] in the GRUB page.<br />
* A sample {{ic|/boot/grub/grub.cfg}} gets installed as part of the {{Pkg|grub}} package, and subsequent {{ic|grub-*}} commands may not over-write it. Ensure that your intended changes are in {{ic|grub.cfg}}, rather than in {{ic|grub.cfg.new}} or some such file.<br />
}}<br />
<br />
While using a manually created {{ic|grub.cfg}} is absolutely fine, it is recommended that beginners automatically generate one:<br />
<br />
{{Tip|To automatically search for other operating systems on your computer, install {{Pkg|os-prober}} ({{ic|pacman -S os-prober}}) before running the next command.}}<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|It is possible that multiple redundant menu entries will be generated. See [[GRUB#Redundant_menu_entries]].}}<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
==== For UEFI motherboards ====<br />
<br />
For UEFI systems, several boot loaders are available, see [[Boot loaders]] for a complete list. Choose one as per your convenience. Here, two of the possibilities are given as examples:<br />
<br />
* [[gummiboot]] is a minimal UEFI Boot Manager which provides a menu for [[EFISTUB]] kernels and other UEFI applications.<br />
* [[GRUB]] is a more complete bootloader, useful if you run into problems with Gummiboot.<br />
<br />
No matter which one you choose, first install the {{Pkg|dosfstools}} package, so you can manipulate your EFI System Partition after installation:<br />
<br />
# pacman -S dosfstools<br />
<br />
{{Note|For UEFI boot, the drive needs to be GPT-partitioned and an [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] (512 MiB or larger, gdisk type {{ic|EF00}}, formatted with FAT32) must be present. In the following examples, this partition is assumed to be mounted at {{ic|/boot}}. If you have followed this guide from the beginning, you have already done all of these.}}<br />
<br />
===== Gummiboot =====<br />
<br />
Install the {{Pkg|gummiboot}} package and run {{ic|gummiboot install}} to install the bootloader to the EFI System Partition:<br />
<br />
# pacman -S gummiboot<br />
# gummiboot install<br />
<br />
{{Warning|Gummiboot and the Linux Kernel will not automatically update if your EFI System Partition is not mounted at {{ic|/boot}}.}}<br />
<br />
You will need to manually create a configuration file to add an entry for Arch Linux to the gummiboot manager. Create {{ic|/boot/loader/entries/arch.conf}} and add the following contents, replacing {{ic|/dev/sdaX}} with your '''root''' partition, usually {{ic|/dev/sda2}}:<br />
<br />
{{hc|# nano /boot/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root='''/dev/sdaX''' rw<br />
}}<br />
<br />
For more information on configuring and using gummiboot, see [[gummiboot]].<br />
<br />
===== GRUB =====<br />
<br />
Install the {{Pkg|grub}} and {{Pkg|efibootmgr}} packages and run {{ic|grub-install}} to install the bootloader:<br />
<br />
# pacman -S grub efibootmgr<br />
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch_grub --recheck<br />
<br />
Next, while using a manually created {{ic|grub.cfg}} is absolutely fine, it is recommended that beginners automatically generate one:<br />
<br />
{{Tip|To automatically search for other operating systems on your computer, install {{Pkg|os-prober}} before running the next command. However ''os-prober'' is not known to properly detect UEFI OSes.}}<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
=== Unmount the partitions and reboot ===<br />
<br />
Exit from the chroot environment:<br />
<br />
# exit<br />
<br />
Reboot the computer:<br />
<br />
# reboot<br />
<br />
{{Tip|Be sure to remove the installation media, otherwise you will boot back into it.}}<br />
<br />
== Post-installation ==<br />
<br />
Your new Arch Linux base system is now a functional GNU/Linux environment ready to be built into whatever you wish or require for your purposes. You are now ''strongly'' advised to read [[General recommendations#System administration]] and [[General recommendations#Package management]].<br />
<br />
See the rest of the [[General recommendations]] article for post-installation tutorials like setting up a graphical user interface, sound or a touchpad.<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Bwidhttps://wiki.archlinux.org/index.php?title=GRUB&diff=333754GRUB2014-09-04T06:52:33Z<p>Bwid: /* GUID Partition Table (GPT) specific instructions */ setting boot-flag on partition in protective-mbr isn't normally required.</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
<br />
On a BIOS - [[GPT]] configuration, a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] is required. GRUB embeds its {{ic|core.img}} into this partition.<br />
<br />
{{Note| This partition is only needed for the GRUB - BIOS - GPT combination. The reason is that on a [[Master_Boot_Record|MBR]] system, GRUB uses the so called post-MBR gap to embed the image. On a [[GUID_Partition_Table|GPT]] system, the spot where the post-MBR gap was is taken over by the GPT Primary Header and Primary Partition table, so GRUB can no longer use it for this purpose. This extra partition is also not required if the system is [[UEFI]] based, as no embedding of boot sectors takes place in that case.<br />
}}<br />
<br />
Create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no file system. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. In rare cases you may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes will refuse to boot.<br />
<br />
{{Tip|<br />
* You will probably need to explicitly set the {{ic|grub-install}} target to {{ic|i386-pc}} using {{ic|<nowiki>--target=i386-pc</nowiki>}}. Otherwise {{ic|grub-install}} sometimes guesses that your configuration is EFI-GPT.<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 4 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to external USB stick|Install to external USB stick]] (for recovery)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to external USB stick =====<br />
Assume your USB stick's first partition is FAT32 and it's partition is /dev/sdy1<br />
<br />
# mkdir -p /tmp/y ; mount /dev/sdy1 /tmp/y <br />
# grub-install --target=i386-pc --recheck --debug --boot-directory=/tmp/y/boot /dev/sdy<br />
# grub-mkconfig -o /tmp/y/boot/grub/grub.cfg<br />
<br />
# optional, backup config files of grub.cfg<br />
# mkdir -p /tmp/y/etc/default<br />
# cp /etc/default/grub /tmp/y/etc/default<br />
# cp -a /etc/grub.d /tmp/y/etc<br />
<br />
# sync ; umount /tmp/y<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partition (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed. Do not forget to [[#Generating main configuration file|generate the main configuration file]].<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath}/grub.cfg should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
{{Warning|You may find that the {{ic|grub.cfg}} file is not loaded due to {{ic|${cmdpath} }} missing a slash (i.e. {{ic|(hd1,msdos2)EFI/Boot}} instead of {{ic|(hd1,msdos2)/EFI/Boot}}) and so you are dropped into a GRUB shell. If this happens determine what {{ic|${cmdpath} }} is set to ({{ic|echo ${cmdpath} }}) and then load the config file manually (e.g. {{ic|configfile (hd1,msdos2)/EFI/Boot/grub.cfg}}).}}<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Disable Submenu ===<br />
If you have multiple kernels installed, say linux and linux-lts, by default {{ic|grub-mkconfig}} groups them in a submenu. <br />
If you do not like this behaviour you can go back to one single menu by adding the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_SUBMENU=y<br />
<br />
=== Root encryption ===<br />
<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
See [[Dm-crypt/System Configuration#Boot loader]] for more details.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
{{Accuracy|1=The following step was added with [https://wiki.archlinux.org/index.php?title=GRUB&diff=184194&oldid=183020], but there is not a clear reason to disable the usage of UUIDs for the root file system.}}<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Tip|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode (as per alternate method):<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the uefi bitness. It '''WILL NOT WORK''' in bios installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations|this]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations|this]] for more info.}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands. {{ic|$fs_uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually C:). In {{ic|blkid}} output, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
{{Note|These menuentries will work only in Legacy BIOS boot mode. It WILL NOT WORK in uefi installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations]].}}<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting ISO9660 image file directly via GRUB ===<br />
{{Poor writing|The only boxes used should be code blocks, otherwise the section will be unreadable. Anything else should be plain text.}}<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO image file and update the boot menu accordingly, for example:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Here are some examples about booting different distributions' LiveCD.<br />
{{Note|<br />
* The following examples assume the ISO image exists at {{ic|/boot/iso}} on {{ic|hd1,2}}(i.e.{{ic|/dev/sdb2}}).<br />
* Not all distributions' ISO image can boot that way (e.g. CentOS ≤ 6.5), so when you try to boot other distribution's ISO which is or not listed here and it is stuck, please looking for related documentation and wiki pages or ask for help in the related community.}}<br />
{{tip|The prefix {{ic|'''(hd1,2)'''}} before {{ic|$isofile}}(also {{ic|$initrdfile}} and any other similar) can be omitted when the grub directory(the directory includes GRUB config files and modules, e.g. {{ic|/boot/grub}}) and the ISO images are in the same partition. This is recommended for thumbdrives.}}<br />
<br />
==== Arch Linux ====<br />
{{Tip|If you want to boot into a 32-bit system, replace {{ic|x86_64}} with {{ic|i686}}.}}<br />
===== monthly release =====<br />
{{bc|1=menuentry '[loopback]archlinux-2014.08.01-dual.iso' {<br />
set isofile='/boot/iso/archlinux-2014.08.01-dual.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/arch/boot/'''x86_64'''/vmlinuz archisolabel=ARCH_'''201408''' img_dev='''/dev/sdb2''' img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/'''x86_64'''/archiso.img<br />
}<br />
}}<br />
{{note|<br />
* It's recommend for thumbdrives to use [[Persistent block device naming|a persistent name]] instead of {{ic|/dev/sd'''''xY'''''}} for the {{ic|img_dev}} parameter, e.g. {{ic|1=img_dev=/dev/disk/by-label/MYUSBSTICK}} (or {{ic|1=img_label=MYUSBSTICK}}).<br />
* As the official monthly release build script [https://projects.archlinux.org/archiso.git/tree/configs/releng/build.sh#n6 defines], you need to edit the label string after {{ic|1=archisolabel=}} when you use a newer monthly released ISO image.<br />
* For a complete list of archiso boot parameters, please see its [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams documentation].}}<br />
<br />
===== archboot =====<br />
See also: [[Archboot]]<br />
{{bc|1=<br />
menuentry '[loopback]archlinux-2014.08-1-archboot' {<br />
set isofile='/boot/iso/archlinux-2014.08-1-archboot.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/boot/vmlinuz_'''x86_64''' iso_loop_dev='''/dev/sdb2''' iso_loop_path=$isofile<br />
initrd (loop)/boot/initramfs_'''x86_64'''.img<br />
}<br />
}}<br />
<br />
==== CentOS ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-DVD' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-DVD.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|The boot parameter {{ic|1=inst.stage2=hd:}} which is used by [https://fedoraproject.org/wiki/Anaconda anaconda], is similar to [[fstab]]'s first field(fs_spec):<br />
* {{ic|1=inst.stage2=hd:/dev/sd'''''xY'''''}}<br />
* {{ic|1=inst.stage2=hd:LABEL=MYUSBSTICK}}<br />
* {{ic|1=inst.stage2=hd:UUID=00000000-0000-0000-0000-0000deadbeef}}<br />
}}<br />
<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-GnomeLive' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-GnomeLive.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=CentOS-7-live-GNOME-x86_64 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Debian ====<br />
===== Stock install medium =====<br />
{{note|To install debian from any stock install medium on a hard disk(or usb stick), it's necessary to use a different initramfs instead of the default one on the installation medium(it is located at {{ic|(loop)/install.amd/initrd.gz}}). If you boot with the default one, the [https://www.debian.org/devel/debian-installer/ debian-installer] will unable to find or mount the proper iso image for installation. Please download the initramfs for hard disk installation from [https://mirrors.kernel.org/debian/dists/stable/main/installer-amd64/current/images/hd-media/initrd.gz an official mirror site], put it in the same directory with the image file and give it a suitable name({{ic|debian-7.6.0-amd64-DVD-1.hdd.initrd.gz}} in this example).}}<br />
{{bc|1=menuentry '[loopback]debian-7.6.0-amd64-DVD-1' {<br />
set isofile='/boot/iso/debian-7.6.0-amd64-DVD-1.iso'<br />
set initrdfile='/boot/iso/debian-7.6.0-amd64-DVD-1.hdd.initrd.gz'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/install.amd/vmlinuz vga=791 iso-scan/ask_second_pass=true iso-scan/filename=$isofile<br />
initrd '''(hd1,2)'''$initrdfile<br />
}<br />
}}<br />
===== Live install medium =====<br />
{{bc|1=menuentry '[loopback]debian-live-7.6.0-amd64-xfce-desktop' {<br />
set isofile='/boot/iso/debian-live-7.6.0-amd64-xfce-desktop.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live config fromiso='''/dev/sdb2'''/$isofile<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
{{note|It's also OK to use {{ic|1=findiso=$isofile}} instead of the longer {{ic|1=fromiso=/dev/disk/by-.../.../$isofile}}. Anyway, using {{ic|1=fromiso=}} instead of {{ic|1=findiso=}} may speed up the initialization progress because it avoids unnecessary mounting.}}<br />
<br />
==== Fedora ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-20-x86_64-DVD' {<br />
set isofile='/boot/iso/Fedora-20-x86_64-DVD.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|For a list of [https://fedoraproject.org/wiki/Anaconda anaconda] boot parameters, please see this [https://git.fedorahosted.org/cgit/anaconda.git/tree/docs/boot-options.txt documentation].}}<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-Live-Desktop-x86_64-20-1' {<br />
set isofile='/boot/iso/Fedora-Live-Desktop-x86_64-20-1.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-1 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Kali Linux ====<br />
{{bc|1=menuentry '[loopback]kali-linux-1.0.7-amd64' {<br />
set isofile='/boot/iso/kali-linux-1.0.7-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live findiso=$isofile noconfig=sudo username=root hostname=kali<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
<br />
==== openSUSE ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-DVD-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-DVD-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux install=hd:$isofile<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
===== LiveCD =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-KDE-Live-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-KDE-Live-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux isofrom_device='''/dev/sdb2''' isofrom_system=$isofile LANG='''en_US.UTF-8'''<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
<br />
==== Sabayon ====<br />
{{bc|1=<br />
menuentry '[loopback]Sabayon_Linux_14.05_amd64_KDE' {<br />
set isofile='/boot/iso/Sabayon_Linux_14.05_amd64_KDE.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/sabayon root=/dev/ram0 aufs cdroot locale='''en_US''' loop=/livecd.squashfs looptype=squashfs isoboot=$isofile<br />
initrd (loop)/boot/sabayon.igz<br />
}<br />
}}<br />
<br />
==== Slackware Linux ====<br />
{{bc|1=menuentry '[loopback]slackware64-14.1-install-dvd' {<br />
set isofile='/boot/iso/slackware64-14.1-install-dvd.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/kernels/huge.s/bzImage printk.time=0<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
<br />
==== Ubuntu ====<br />
{{bc|1=menuentry '[loopback]ubuntu-14.04-desktop-amd64' {<br />
set isofile='/boot/iso/ubuntu-14.04-desktop-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile locale='''en_US.UTF-8'''<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
}}<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/40_custom}}:<br />
<br />
{{hc|/etc/grub.d/40_custom|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created and made executable:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
Make that file executable and then regenerate your grub config:<br />
chmod a+x /etc/grub.d/31_hold_shift<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>Bwidhttps://wiki.archlinux.org/index.php?title=GRUB&diff=333714GRUB2014-09-03T18:29:23Z<p>Bwid: /* BIOS systems */ remove redundancy</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
<br />
On a BIOS - [[GPT]] configuration, a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] is required. GRUB embeds its {{ic|core.img}} into this partition.<br />
<br />
{{Note| This partition is only needed for the GRUB - BIOS - GPT combination. The reason is that on a [[Master_Boot_Record|MBR]] system, GRUB uses the so called post-MBR gap to embed the image. On a [[GUID_Partition_Table|GPT]] system, the spot where the post-MBR gap was is taken over by the GPT Primary Header and Primary Partition table, so GRUB can no longer use it for this purpose. This extra partition is also not required if the system is [[UEFI]] based, as no embedding of boot sectors takes place in that case.<br />
}}<br />
<br />
Create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no file system. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Tip|<br />
* You will probably need to explicitly set the {{ic|grub-install}} target to {{ic|i386-pc}} using {{ic|<nowiki>--target=i386-pc</nowiki>}}. Otherwise {{ic|grub-install}} sometimes guesses that your configuration is EFI-GPT.<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 4 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to external USB stick|Install to external USB stick]] (for recovery)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to external USB stick =====<br />
Assume your USB stick's first partition is FAT32 and it's partition is /dev/sdy1<br />
<br />
# mkdir -p /tmp/y ; mount /dev/sdy1 /tmp/y <br />
# grub-install --target=i386-pc --recheck --debug --boot-directory=/tmp/y/boot /dev/sdy<br />
# grub-mkconfig -o /tmp/y/boot/grub/grub.cfg<br />
<br />
# optional, backup config files of grub.cfg<br />
# mkdir -p /tmp/y/etc/default<br />
# cp /etc/default/grub /tmp/y/etc/default<br />
# cp -a /etc/grub.d /tmp/y/etc<br />
<br />
# sync ; umount /tmp/y<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partition (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed. Do not forget to [[#Generating main configuration file|generate the main configuration file]].<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath}/grub.cfg should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
{{Warning|You may find that the {{ic|grub.cfg}} file is not loaded due to {{ic|${cmdpath} }} missing a slash (i.e. {{ic|(hd1,msdos2)EFI/Boot}} instead of {{ic|(hd1,msdos2)/EFI/Boot}}) and so you are dropped into a GRUB shell. If this happens determine what {{ic|${cmdpath} }} is set to ({{ic|echo ${cmdpath} }}) and then load the config file manually (e.g. {{ic|configfile (hd1,msdos2)/EFI/Boot/grub.cfg}}).}}<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Disable Submenu ===<br />
If you have multiple kernels installed, say linux and linux-lts, by default {{ic|grub-mkconfig}} groups them in a submenu. <br />
If you do not like this behaviour you can go back to one single menu by adding the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_SUBMENU=y<br />
<br />
=== Root encryption ===<br />
<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
See [[Dm-crypt/System Configuration#Boot loader]] for more details.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
{{Accuracy|1=The following step was added with [https://wiki.archlinux.org/index.php?title=GRUB&diff=184194&oldid=183020], but there is not a clear reason to disable the usage of UUIDs for the root file system.}}<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Tip|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode (as per alternate method):<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the uefi bitness. It '''WILL NOT WORK''' in bios installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations|this]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations|this]] for more info.}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands. {{ic|$fs_uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually C:). In {{ic|blkid}} output, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
{{Note|These menuentries will work only in Legacy BIOS boot mode. It WILL NOT WORK in uefi installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations]].}}<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting ISO9660 image file directly via GRUB ===<br />
{{Poor writing|The only boxes used should be code blocks, otherwise the section will be unreadable. Anything else should be plain text.}}<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO image file and update the boot menu accordingly, for example:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Here are some examples about booting different distributions' LiveCD.<br />
{{Note|<br />
* The following examples assume the ISO image exists at {{ic|/boot/iso}} on {{ic|hd1,2}}(i.e.{{ic|/dev/sdb2}}).<br />
* Not all distributions' ISO image can boot that way (e.g. CentOS ≤ 6.5), so when you try to boot other distribution's ISO which is or not listed here and it is stuck, please looking for related documentation and wiki pages or ask for help in the related community.}}<br />
{{tip|The prefix {{ic|'''(hd1,2)'''}} before {{ic|$isofile}}(also {{ic|$initrdfile}} and any other similar) can be omitted when the grub directory(the directory includes GRUB config files and modules, e.g. {{ic|/boot/grub}}) and the ISO images are in the same partition. This is recommended for thumbdrives.}}<br />
<br />
==== Arch Linux ====<br />
{{Tip|If you want to boot into a 32-bit system, replace {{ic|x86_64}} with {{ic|i686}}.}}<br />
===== monthly release =====<br />
{{bc|1=menuentry '[loopback]archlinux-2014.08.01-dual.iso' {<br />
set isofile='/boot/iso/archlinux-2014.08.01-dual.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/arch/boot/'''x86_64'''/vmlinuz archisolabel=ARCH_'''201408''' img_dev='''/dev/sdb2''' img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/'''x86_64'''/archiso.img<br />
}<br />
}}<br />
{{note|<br />
* It's recommend for thumbdrives to use [[Persistent block device naming|a persistent name]] instead of {{ic|/dev/sd'''''xY'''''}} for the {{ic|img_dev}} parameter, e.g. {{ic|1=img_dev=/dev/disk/by-label/MYUSBSTICK}} (or {{ic|1=img_label=MYUSBSTICK}}).<br />
* As the official monthly release build script [https://projects.archlinux.org/archiso.git/tree/configs/releng/build.sh#n6 defines], you need to edit the label string after {{ic|1=archisolabel=}} when you use a newer monthly released ISO image.<br />
* For a complete list of archiso boot parameters, please see its [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams documentation].}}<br />
<br />
===== archboot =====<br />
See also: [[Archboot]]<br />
{{bc|1=<br />
menuentry '[loopback]archlinux-2014.08-1-archboot' {<br />
set isofile='/boot/iso/archlinux-2014.08-1-archboot.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/boot/vmlinuz_'''x86_64''' iso_loop_dev='''/dev/sdb2''' iso_loop_path=$isofile<br />
initrd (loop)/boot/initramfs_'''x86_64'''.img<br />
}<br />
}}<br />
<br />
==== CentOS ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-DVD' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-DVD.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|The boot parameter {{ic|1=inst.stage2=hd:}} which is used by [https://fedoraproject.org/wiki/Anaconda anaconda], is similar to [[fstab]]'s first field(fs_spec):<br />
* {{ic|1=inst.stage2=hd:/dev/sd'''''xY'''''}}<br />
* {{ic|1=inst.stage2=hd:LABEL=MYUSBSTICK}}<br />
* {{ic|1=inst.stage2=hd:UUID=00000000-0000-0000-0000-0000deadbeef}}<br />
}}<br />
<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-GnomeLive' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-GnomeLive.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=CentOS-7-live-GNOME-x86_64 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Debian ====<br />
===== Stock install medium =====<br />
{{note|To install debian from any stock install medium on a hard disk(or usb stick), it's necessary to use a different initramfs instead of the default one on the installation medium(it is located at {{ic|(loop)/install.amd/initrd.gz}}). If you boot with the default one, the [https://www.debian.org/devel/debian-installer/ debian-installer] will unable to find or mount the proper iso image for installation. Please download the initramfs for hard disk installation from [https://mirrors.kernel.org/debian/dists/stable/main/installer-amd64/current/images/hd-media/initrd.gz an official mirror site], put it in the same directory with the image file and give it a suitable name({{ic|debian-7.6.0-amd64-DVD-1.hdd.initrd.gz}} in this example).}}<br />
{{bc|1=menuentry '[loopback]debian-7.6.0-amd64-DVD-1' {<br />
set isofile='/boot/iso/debian-7.6.0-amd64-DVD-1.iso'<br />
set initrdfile='/boot/iso/debian-7.6.0-amd64-DVD-1.hdd.initrd.gz'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/install.amd/vmlinuz vga=791 iso-scan/ask_second_pass=true iso-scan/filename=$isofile<br />
initrd '''(hd1,2)'''$initrdfile<br />
}<br />
}}<br />
===== Live install medium =====<br />
{{bc|1=menuentry '[loopback]debian-live-7.6.0-amd64-xfce-desktop' {<br />
set isofile='/boot/iso/debian-live-7.6.0-amd64-xfce-desktop.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live config fromiso='''/dev/sdb2'''/$isofile<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
{{note|It's also OK to use {{ic|1=findiso=$isofile}} instead of the longer {{ic|1=fromiso=/dev/disk/by-.../.../$isofile}}. Anyway, using {{ic|1=fromiso=}} instead of {{ic|1=findiso=}} may speed up the initialization progress because it avoids unnecessary mounting.}}<br />
<br />
==== Fedora ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-20-x86_64-DVD' {<br />
set isofile='/boot/iso/Fedora-20-x86_64-DVD.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|For a list of [https://fedoraproject.org/wiki/Anaconda anaconda] boot parameters, please see this [https://git.fedorahosted.org/cgit/anaconda.git/tree/docs/boot-options.txt documentation].}}<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-Live-Desktop-x86_64-20-1' {<br />
set isofile='/boot/iso/Fedora-Live-Desktop-x86_64-20-1.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-1 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Kali Linux ====<br />
{{bc|1=menuentry '[loopback]kali-linux-1.0.7-amd64' {<br />
set isofile='/boot/iso/kali-linux-1.0.7-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live findiso=$isofile noconfig=sudo username=root hostname=kali<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
<br />
==== openSUSE ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-DVD-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-DVD-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux install=hd:$isofile<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
===== LiveCD =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-KDE-Live-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-KDE-Live-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux isofrom_device='''/dev/sdb2''' isofrom_system=$isofile LANG='''en_US.UTF-8'''<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
<br />
==== Sabayon ====<br />
{{bc|1=<br />
menuentry '[loopback]Sabayon_Linux_14.05_amd64_KDE' {<br />
set isofile='/boot/iso/Sabayon_Linux_14.05_amd64_KDE.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/sabayon root=/dev/ram0 aufs cdroot locale='''en_US''' loop=/livecd.squashfs looptype=squashfs isoboot=$isofile<br />
initrd (loop)/boot/sabayon.igz<br />
}<br />
}}<br />
<br />
==== Slackware Linux ====<br />
{{bc|1=menuentry '[loopback]slackware64-14.1-install-dvd' {<br />
set isofile='/boot/iso/slackware64-14.1-install-dvd.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/kernels/huge.s/bzImage printk.time=0<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
<br />
==== Ubuntu ====<br />
{{bc|1=menuentry '[loopback]ubuntu-14.04-desktop-amd64' {<br />
set isofile='/boot/iso/ubuntu-14.04-desktop-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile locale='''en_US.UTF-8'''<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
}}<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/40_custom}}:<br />
<br />
{{hc|/etc/grub.d/40_custom|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created and made executable:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
Make that file executable and then regenerate your grub config:<br />
chmod a+x /etc/grub.d/31_hold_shift<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>Bwidhttps://wiki.archlinux.org/index.php?title=GRUB&diff=333713GRUB2014-09-03T18:26:42Z<p>Bwid: /* GUID Partition Table (GPT) specific instructions */ change Note section, which makes 3 points which the user will most likely make use of, to Tip</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
<br />
On a BIOS - [[GPT]] configuration, a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] is required. GRUB embeds its {{ic|core.img}} into this partition.<br />
<br />
{{Note| This partition is only needed for the GRUB - BIOS - GPT combination. The reason is that on a [[Master_Boot_Record|MBR]] system, GRUB uses the so called post-MBR gap to embed the image. On a [[GUID_Partition_Table|GPT]] system, the spot where the post-MBR gap was is taken over by the GPT Primary Header and Primary Partition table, so GRUB can no longer use it for this purpose. This extra partition is also not required if the system is [[UEFI]] based, as no embedding of boot sectors takes place in that case.<br />
}}<br />
<br />
For a BIOS-GPT configuration, create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no file system. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Tip|<br />
* You will probably need to explicitly set the {{ic|grub-install}} target to {{ic|i386-pc}} using {{ic|<nowiki>--target=i386-pc</nowiki>}}. Otherwise {{ic|grub-install}} sometimes guesses that your configuration is EFI-GPT.<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 4 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to external USB stick|Install to external USB stick]] (for recovery)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to external USB stick =====<br />
Assume your USB stick's first partition is FAT32 and it's partition is /dev/sdy1<br />
<br />
# mkdir -p /tmp/y ; mount /dev/sdy1 /tmp/y <br />
# grub-install --target=i386-pc --recheck --debug --boot-directory=/tmp/y/boot /dev/sdy<br />
# grub-mkconfig -o /tmp/y/boot/grub/grub.cfg<br />
<br />
# optional, backup config files of grub.cfg<br />
# mkdir -p /tmp/y/etc/default<br />
# cp /etc/default/grub /tmp/y/etc/default<br />
# cp -a /etc/grub.d /tmp/y/etc<br />
<br />
# sync ; umount /tmp/y<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partition (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed. Do not forget to [[#Generating main configuration file|generate the main configuration file]].<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath}/grub.cfg should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
{{Warning|You may find that the {{ic|grub.cfg}} file is not loaded due to {{ic|${cmdpath} }} missing a slash (i.e. {{ic|(hd1,msdos2)EFI/Boot}} instead of {{ic|(hd1,msdos2)/EFI/Boot}}) and so you are dropped into a GRUB shell. If this happens determine what {{ic|${cmdpath} }} is set to ({{ic|echo ${cmdpath} }}) and then load the config file manually (e.g. {{ic|configfile (hd1,msdos2)/EFI/Boot/grub.cfg}}).}}<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Disable Submenu ===<br />
If you have multiple kernels installed, say linux and linux-lts, by default {{ic|grub-mkconfig}} groups them in a submenu. <br />
If you do not like this behaviour you can go back to one single menu by adding the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_SUBMENU=y<br />
<br />
=== Root encryption ===<br />
<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
See [[Dm-crypt/System Configuration#Boot loader]] for more details.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
{{Accuracy|1=The following step was added with [https://wiki.archlinux.org/index.php?title=GRUB&diff=184194&oldid=183020], but there is not a clear reason to disable the usage of UUIDs for the root file system.}}<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Tip|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode (as per alternate method):<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the uefi bitness. It '''WILL NOT WORK''' in bios installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations|this]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations|this]] for more info.}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands. {{ic|$fs_uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually C:). In {{ic|blkid}} output, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
{{Note|These menuentries will work only in Legacy BIOS boot mode. It WILL NOT WORK in uefi installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations]].}}<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting ISO9660 image file directly via GRUB ===<br />
{{Poor writing|The only boxes used should be code blocks, otherwise the section will be unreadable. Anything else should be plain text.}}<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO image file and update the boot menu accordingly, for example:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Here are some examples about booting different distributions' LiveCD.<br />
{{Note|<br />
* The following examples assume the ISO image exists at {{ic|/boot/iso}} on {{ic|hd1,2}}(i.e.{{ic|/dev/sdb2}}).<br />
* Not all distributions' ISO image can boot that way (e.g. CentOS ≤ 6.5), so when you try to boot other distribution's ISO which is or not listed here and it is stuck, please looking for related documentation and wiki pages or ask for help in the related community.}}<br />
{{tip|The prefix {{ic|'''(hd1,2)'''}} before {{ic|$isofile}}(also {{ic|$initrdfile}} and any other similar) can be omitted when the grub directory(the directory includes GRUB config files and modules, e.g. {{ic|/boot/grub}}) and the ISO images are in the same partition. This is recommended for thumbdrives.}}<br />
<br />
==== Arch Linux ====<br />
{{Tip|If you want to boot into a 32-bit system, replace {{ic|x86_64}} with {{ic|i686}}.}}<br />
===== monthly release =====<br />
{{bc|1=menuentry '[loopback]archlinux-2014.08.01-dual.iso' {<br />
set isofile='/boot/iso/archlinux-2014.08.01-dual.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/arch/boot/'''x86_64'''/vmlinuz archisolabel=ARCH_'''201408''' img_dev='''/dev/sdb2''' img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/'''x86_64'''/archiso.img<br />
}<br />
}}<br />
{{note|<br />
* It's recommend for thumbdrives to use [[Persistent block device naming|a persistent name]] instead of {{ic|/dev/sd'''''xY'''''}} for the {{ic|img_dev}} parameter, e.g. {{ic|1=img_dev=/dev/disk/by-label/MYUSBSTICK}} (or {{ic|1=img_label=MYUSBSTICK}}).<br />
* As the official monthly release build script [https://projects.archlinux.org/archiso.git/tree/configs/releng/build.sh#n6 defines], you need to edit the label string after {{ic|1=archisolabel=}} when you use a newer monthly released ISO image.<br />
* For a complete list of archiso boot parameters, please see its [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams documentation].}}<br />
<br />
===== archboot =====<br />
See also: [[Archboot]]<br />
{{bc|1=<br />
menuentry '[loopback]archlinux-2014.08-1-archboot' {<br />
set isofile='/boot/iso/archlinux-2014.08-1-archboot.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/boot/vmlinuz_'''x86_64''' iso_loop_dev='''/dev/sdb2''' iso_loop_path=$isofile<br />
initrd (loop)/boot/initramfs_'''x86_64'''.img<br />
}<br />
}}<br />
<br />
==== CentOS ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-DVD' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-DVD.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|The boot parameter {{ic|1=inst.stage2=hd:}} which is used by [https://fedoraproject.org/wiki/Anaconda anaconda], is similar to [[fstab]]'s first field(fs_spec):<br />
* {{ic|1=inst.stage2=hd:/dev/sd'''''xY'''''}}<br />
* {{ic|1=inst.stage2=hd:LABEL=MYUSBSTICK}}<br />
* {{ic|1=inst.stage2=hd:UUID=00000000-0000-0000-0000-0000deadbeef}}<br />
}}<br />
<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-GnomeLive' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-GnomeLive.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=CentOS-7-live-GNOME-x86_64 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Debian ====<br />
===== Stock install medium =====<br />
{{note|To install debian from any stock install medium on a hard disk(or usb stick), it's necessary to use a different initramfs instead of the default one on the installation medium(it is located at {{ic|(loop)/install.amd/initrd.gz}}). If you boot with the default one, the [https://www.debian.org/devel/debian-installer/ debian-installer] will unable to find or mount the proper iso image for installation. Please download the initramfs for hard disk installation from [https://mirrors.kernel.org/debian/dists/stable/main/installer-amd64/current/images/hd-media/initrd.gz an official mirror site], put it in the same directory with the image file and give it a suitable name({{ic|debian-7.6.0-amd64-DVD-1.hdd.initrd.gz}} in this example).}}<br />
{{bc|1=menuentry '[loopback]debian-7.6.0-amd64-DVD-1' {<br />
set isofile='/boot/iso/debian-7.6.0-amd64-DVD-1.iso'<br />
set initrdfile='/boot/iso/debian-7.6.0-amd64-DVD-1.hdd.initrd.gz'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/install.amd/vmlinuz vga=791 iso-scan/ask_second_pass=true iso-scan/filename=$isofile<br />
initrd '''(hd1,2)'''$initrdfile<br />
}<br />
}}<br />
===== Live install medium =====<br />
{{bc|1=menuentry '[loopback]debian-live-7.6.0-amd64-xfce-desktop' {<br />
set isofile='/boot/iso/debian-live-7.6.0-amd64-xfce-desktop.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live config fromiso='''/dev/sdb2'''/$isofile<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
{{note|It's also OK to use {{ic|1=findiso=$isofile}} instead of the longer {{ic|1=fromiso=/dev/disk/by-.../.../$isofile}}. Anyway, using {{ic|1=fromiso=}} instead of {{ic|1=findiso=}} may speed up the initialization progress because it avoids unnecessary mounting.}}<br />
<br />
==== Fedora ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-20-x86_64-DVD' {<br />
set isofile='/boot/iso/Fedora-20-x86_64-DVD.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|For a list of [https://fedoraproject.org/wiki/Anaconda anaconda] boot parameters, please see this [https://git.fedorahosted.org/cgit/anaconda.git/tree/docs/boot-options.txt documentation].}}<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-Live-Desktop-x86_64-20-1' {<br />
set isofile='/boot/iso/Fedora-Live-Desktop-x86_64-20-1.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-1 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Kali Linux ====<br />
{{bc|1=menuentry '[loopback]kali-linux-1.0.7-amd64' {<br />
set isofile='/boot/iso/kali-linux-1.0.7-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live findiso=$isofile noconfig=sudo username=root hostname=kali<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
<br />
==== openSUSE ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-DVD-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-DVD-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux install=hd:$isofile<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
===== LiveCD =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-KDE-Live-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-KDE-Live-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux isofrom_device='''/dev/sdb2''' isofrom_system=$isofile LANG='''en_US.UTF-8'''<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
<br />
==== Sabayon ====<br />
{{bc|1=<br />
menuentry '[loopback]Sabayon_Linux_14.05_amd64_KDE' {<br />
set isofile='/boot/iso/Sabayon_Linux_14.05_amd64_KDE.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/sabayon root=/dev/ram0 aufs cdroot locale='''en_US''' loop=/livecd.squashfs looptype=squashfs isoboot=$isofile<br />
initrd (loop)/boot/sabayon.igz<br />
}<br />
}}<br />
<br />
==== Slackware Linux ====<br />
{{bc|1=menuentry '[loopback]slackware64-14.1-install-dvd' {<br />
set isofile='/boot/iso/slackware64-14.1-install-dvd.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/kernels/huge.s/bzImage printk.time=0<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
<br />
==== Ubuntu ====<br />
{{bc|1=menuentry '[loopback]ubuntu-14.04-desktop-amd64' {<br />
set isofile='/boot/iso/ubuntu-14.04-desktop-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile locale='''en_US.UTF-8'''<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
}}<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/40_custom}}:<br />
<br />
{{hc|/etc/grub.d/40_custom|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created and made executable:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
Make that file executable and then regenerate your grub config:<br />
chmod a+x /etc/grub.d/31_hold_shift<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>Bwidhttps://wiki.archlinux.org/index.php?title=GRUB&diff=333712GRUB2014-09-03T18:23:58Z<p>Bwid: /* GUID Partition Table (GPT) specific instructions */</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
<br />
On a BIOS - [[GPT]] configuration, a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] is required. GRUB embeds its {{ic|core.img}} into this partition.<br />
<br />
{{Note| This partition is only needed for the GRUB - BIOS - GPT combination. The reason is that on a [[Master_Boot_Record|MBR]] system, GRUB uses the so called post-MBR gap to embed the image. On a [[GUID_Partition_Table|GPT]] system, the spot where the post-MBR gap was is taken over by the GPT Primary Header and Primary Partition table, so GRUB can no longer use it for this purpose. This extra partition is also not required if the system is [[UEFI]] based, as no embedding of boot sectors takes place in that case.<br />
}}<br />
<br />
For a BIOS-GPT configuration, create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no file system. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Note|<br />
* You will probably need to explicitly set the {{ic|grub-install}} target to {{ic|i386-pc}} using {{ic|<nowiki>--target=i386-pc</nowiki>}}. Otherwise {{ic|grub-install}} sometimes guesses that your configuration is EFI-GPT.<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 4 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to external USB stick|Install to external USB stick]] (for recovery)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to external USB stick =====<br />
Assume your USB stick's first partition is FAT32 and it's partition is /dev/sdy1<br />
<br />
# mkdir -p /tmp/y ; mount /dev/sdy1 /tmp/y <br />
# grub-install --target=i386-pc --recheck --debug --boot-directory=/tmp/y/boot /dev/sdy<br />
# grub-mkconfig -o /tmp/y/boot/grub/grub.cfg<br />
<br />
# optional, backup config files of grub.cfg<br />
# mkdir -p /tmp/y/etc/default<br />
# cp /etc/default/grub /tmp/y/etc/default<br />
# cp -a /etc/grub.d /tmp/y/etc<br />
<br />
# sync ; umount /tmp/y<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partition (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed. Do not forget to [[#Generating main configuration file|generate the main configuration file]].<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath}/grub.cfg should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
{{Warning|You may find that the {{ic|grub.cfg}} file is not loaded due to {{ic|${cmdpath} }} missing a slash (i.e. {{ic|(hd1,msdos2)EFI/Boot}} instead of {{ic|(hd1,msdos2)/EFI/Boot}}) and so you are dropped into a GRUB shell. If this happens determine what {{ic|${cmdpath} }} is set to ({{ic|echo ${cmdpath} }}) and then load the config file manually (e.g. {{ic|configfile (hd1,msdos2)/EFI/Boot/grub.cfg}}).}}<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Disable Submenu ===<br />
If you have multiple kernels installed, say linux and linux-lts, by default {{ic|grub-mkconfig}} groups them in a submenu. <br />
If you do not like this behaviour you can go back to one single menu by adding the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_SUBMENU=y<br />
<br />
=== Root encryption ===<br />
<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
See [[Dm-crypt/System Configuration#Boot loader]] for more details.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
{{Accuracy|1=The following step was added with [https://wiki.archlinux.org/index.php?title=GRUB&diff=184194&oldid=183020], but there is not a clear reason to disable the usage of UUIDs for the root file system.}}<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Tip|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode (as per alternate method):<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the uefi bitness. It '''WILL NOT WORK''' in bios installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations|this]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations|this]] for more info.}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands. {{ic|$fs_uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually C:). In {{ic|blkid}} output, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
{{Note|These menuentries will work only in Legacy BIOS boot mode. It WILL NOT WORK in uefi installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations]].}}<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting ISO9660 image file directly via GRUB ===<br />
{{Poor writing|The only boxes used should be code blocks, otherwise the section will be unreadable. Anything else should be plain text.}}<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO image file and update the boot menu accordingly, for example:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Here are some examples about booting different distributions' LiveCD.<br />
{{Note|<br />
* The following examples assume the ISO image exists at {{ic|/boot/iso}} on {{ic|hd1,2}}(i.e.{{ic|/dev/sdb2}}).<br />
* Not all distributions' ISO image can boot that way (e.g. CentOS ≤ 6.5), so when you try to boot other distribution's ISO which is or not listed here and it is stuck, please looking for related documentation and wiki pages or ask for help in the related community.}}<br />
{{tip|The prefix {{ic|'''(hd1,2)'''}} before {{ic|$isofile}}(also {{ic|$initrdfile}} and any other similar) can be omitted when the grub directory(the directory includes GRUB config files and modules, e.g. {{ic|/boot/grub}}) and the ISO images are in the same partition. This is recommended for thumbdrives.}}<br />
<br />
==== Arch Linux ====<br />
{{Tip|If you want to boot into a 32-bit system, replace {{ic|x86_64}} with {{ic|i686}}.}}<br />
===== monthly release =====<br />
{{bc|1=menuentry '[loopback]archlinux-2014.08.01-dual.iso' {<br />
set isofile='/boot/iso/archlinux-2014.08.01-dual.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/arch/boot/'''x86_64'''/vmlinuz archisolabel=ARCH_'''201408''' img_dev='''/dev/sdb2''' img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/'''x86_64'''/archiso.img<br />
}<br />
}}<br />
{{note|<br />
* It's recommend for thumbdrives to use [[Persistent block device naming|a persistent name]] instead of {{ic|/dev/sd'''''xY'''''}} for the {{ic|img_dev}} parameter, e.g. {{ic|1=img_dev=/dev/disk/by-label/MYUSBSTICK}} (or {{ic|1=img_label=MYUSBSTICK}}).<br />
* As the official monthly release build script [https://projects.archlinux.org/archiso.git/tree/configs/releng/build.sh#n6 defines], you need to edit the label string after {{ic|1=archisolabel=}} when you use a newer monthly released ISO image.<br />
* For a complete list of archiso boot parameters, please see its [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams documentation].}}<br />
<br />
===== archboot =====<br />
See also: [[Archboot]]<br />
{{bc|1=<br />
menuentry '[loopback]archlinux-2014.08-1-archboot' {<br />
set isofile='/boot/iso/archlinux-2014.08-1-archboot.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/boot/vmlinuz_'''x86_64''' iso_loop_dev='''/dev/sdb2''' iso_loop_path=$isofile<br />
initrd (loop)/boot/initramfs_'''x86_64'''.img<br />
}<br />
}}<br />
<br />
==== CentOS ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-DVD' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-DVD.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|The boot parameter {{ic|1=inst.stage2=hd:}} which is used by [https://fedoraproject.org/wiki/Anaconda anaconda], is similar to [[fstab]]'s first field(fs_spec):<br />
* {{ic|1=inst.stage2=hd:/dev/sd'''''xY'''''}}<br />
* {{ic|1=inst.stage2=hd:LABEL=MYUSBSTICK}}<br />
* {{ic|1=inst.stage2=hd:UUID=00000000-0000-0000-0000-0000deadbeef}}<br />
}}<br />
<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-GnomeLive' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-GnomeLive.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=CentOS-7-live-GNOME-x86_64 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Debian ====<br />
===== Stock install medium =====<br />
{{note|To install debian from any stock install medium on a hard disk(or usb stick), it's necessary to use a different initramfs instead of the default one on the installation medium(it is located at {{ic|(loop)/install.amd/initrd.gz}}). If you boot with the default one, the [https://www.debian.org/devel/debian-installer/ debian-installer] will unable to find or mount the proper iso image for installation. Please download the initramfs for hard disk installation from [https://mirrors.kernel.org/debian/dists/stable/main/installer-amd64/current/images/hd-media/initrd.gz an official mirror site], put it in the same directory with the image file and give it a suitable name({{ic|debian-7.6.0-amd64-DVD-1.hdd.initrd.gz}} in this example).}}<br />
{{bc|1=menuentry '[loopback]debian-7.6.0-amd64-DVD-1' {<br />
set isofile='/boot/iso/debian-7.6.0-amd64-DVD-1.iso'<br />
set initrdfile='/boot/iso/debian-7.6.0-amd64-DVD-1.hdd.initrd.gz'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/install.amd/vmlinuz vga=791 iso-scan/ask_second_pass=true iso-scan/filename=$isofile<br />
initrd '''(hd1,2)'''$initrdfile<br />
}<br />
}}<br />
===== Live install medium =====<br />
{{bc|1=menuentry '[loopback]debian-live-7.6.0-amd64-xfce-desktop' {<br />
set isofile='/boot/iso/debian-live-7.6.0-amd64-xfce-desktop.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live config fromiso='''/dev/sdb2'''/$isofile<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
{{note|It's also OK to use {{ic|1=findiso=$isofile}} instead of the longer {{ic|1=fromiso=/dev/disk/by-.../.../$isofile}}. Anyway, using {{ic|1=fromiso=}} instead of {{ic|1=findiso=}} may speed up the initialization progress because it avoids unnecessary mounting.}}<br />
<br />
==== Fedora ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-20-x86_64-DVD' {<br />
set isofile='/boot/iso/Fedora-20-x86_64-DVD.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|For a list of [https://fedoraproject.org/wiki/Anaconda anaconda] boot parameters, please see this [https://git.fedorahosted.org/cgit/anaconda.git/tree/docs/boot-options.txt documentation].}}<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-Live-Desktop-x86_64-20-1' {<br />
set isofile='/boot/iso/Fedora-Live-Desktop-x86_64-20-1.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-1 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Kali Linux ====<br />
{{bc|1=menuentry '[loopback]kali-linux-1.0.7-amd64' {<br />
set isofile='/boot/iso/kali-linux-1.0.7-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live findiso=$isofile noconfig=sudo username=root hostname=kali<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
<br />
==== openSUSE ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-DVD-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-DVD-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux install=hd:$isofile<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
===== LiveCD =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-KDE-Live-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-KDE-Live-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux isofrom_device='''/dev/sdb2''' isofrom_system=$isofile LANG='''en_US.UTF-8'''<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
<br />
==== Sabayon ====<br />
{{bc|1=<br />
menuentry '[loopback]Sabayon_Linux_14.05_amd64_KDE' {<br />
set isofile='/boot/iso/Sabayon_Linux_14.05_amd64_KDE.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/sabayon root=/dev/ram0 aufs cdroot locale='''en_US''' loop=/livecd.squashfs looptype=squashfs isoboot=$isofile<br />
initrd (loop)/boot/sabayon.igz<br />
}<br />
}}<br />
<br />
==== Slackware Linux ====<br />
{{bc|1=menuentry '[loopback]slackware64-14.1-install-dvd' {<br />
set isofile='/boot/iso/slackware64-14.1-install-dvd.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/kernels/huge.s/bzImage printk.time=0<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
<br />
==== Ubuntu ====<br />
{{bc|1=menuentry '[loopback]ubuntu-14.04-desktop-amd64' {<br />
set isofile='/boot/iso/ubuntu-14.04-desktop-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile locale='''en_US.UTF-8'''<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
}}<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/40_custom}}:<br />
<br />
{{hc|/etc/grub.d/40_custom|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created and made executable:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
Make that file executable and then regenerate your grub config:<br />
chmod a+x /etc/grub.d/31_hold_shift<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>Bwidhttps://wiki.archlinux.org/index.php?title=GRUB&diff=333711GRUB2014-09-03T18:23:15Z<p>Bwid: /* GUID Partition Table (GPT) specific instructions */ move technical explanation, which is not strictly needed for someone just following this as a guide to setup a system, into a Note section</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ja:GRUB]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<br />
{{Related articles start}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB EFI Examples}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
== Preface ==<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
* GRUB supports [[Btrfs]] as root (without a separate {{ic|/boot}} file system) compressed with either zlib or LZO<br />
* GRUB does not support [[F2fs]] as root so you will need a separate {{ic|/boot}} with a supported file system.<br />
<br />
=== Notes for GRUB Legacy users ===<br />
* Upgrading from [[GRUB Legacy]] to GRUB is much the same as freshly installing GRUB. This topic is covered [[#Installation|here]].<br />
* There are differences in the commands of GRUB Legacy and GRUB. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands GRUB commands] before proceeding (e.g. "find" has been replaced with "search").<br />
* GRUB is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
* Device naming has changed between GRUB Legacy and GRUB. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT).<br />
* GRUB is noticeably bigger than GRUB legacy (occupies ~13 MB in {{ic|/boot}}). If you are booting from a separate {{ic|/boot}} partition, and this partition is smaller than 32 MB, you will run into disk space issues, and pacman will refuse to install new kernels.<br />
<br />
==== Backup important data ====<br />
Although a GRUB installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before upgrading to GRUB v2.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (replace {{ic|/dev/sd''X''}} with your actual disk path):<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sd''X'' of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[#Restore GRUB Legacy|Restore GRUB Legacy]].<br />
<br />
=== Preliminary requirements ===<br />
==== BIOS systems ====<br />
===== GUID Partition Table (GPT) specific instructions =====<br />
<br />
On a BIOS - [[GPT]] configuration, a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] is required. GRUB embeds its {{ic|core.img}} into this partition.<br />
<br />
{{Note| This partition is only needed for the GRUB - BIOS - GPT combination. THe reason is that on a [[Master_Boot_Record|MBR]] system, GRUB uses the so called post-MBR gap to embed the image. On a [[GUID_Partition_Table|GPT]] system, the spot where the post-MBR gap was is taken over by the GPT Primary Header and Primary Partition table, so GRUB can no longer use it for this purpose. This extra partition is also not required if the system is [[UEFI]] based, as no embedding of boot sectors takes place in that case.<br />
}}<br />
<br />
For a BIOS-GPT configuration, create a 1007 KiB partition at the beginning of the disk using gdisk, cgdisk or GNU Parted with no file system. The size of 1007 KiB, plus the size of the preceding GPT of 17 KiB, will allow for the following partition to be correctly aligned at 1024 KiB. If needed, the partition can also be located somewhere else on the disk, but it should be within the first 2 TiB region. Set the partition type to {{ic|ef02}} in (c)gdisk or {{ic|set ''BOOT_PART_NUM'' bios_grub on}} in GNU Parted.<br />
<br />
The GPT partition also creates a protective MBR partition to stop unsupported tools from modifying it. You may need to set a bootable flag on this protective MBR e.g., using cfdisk, or some BIOSes/EFIs will refuse to boot. <br />
<br />
{{Note|<br />
* You will probably need to explicitly set the {{ic|grub-install}} target to {{ic|i386-pc}} using {{ic|<nowiki>--target=i386-pc</nowiki>}}. Otherwise {{ic|grub-install}} sometimes guesses that your configuration is EFI-GPT.<br />
* This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run<br />
* gdisk will only allow you to create this partition on the position which will waste the least amount of space (sector 34-2047) if you create it last, after all the other partitions. This is because gdisk will auto-align partitions to 2048-sector boundaries if possible<br />
}}<br />
<br />
===== Master Boot Record (MBR) specific instructions =====<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
==== UEFI systems ====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.}}<br />
<br />
===== Check if you have GPT and an ESP =====<br />
An EFI System Partition (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: GPT". For EFI, you are looking for a small (512 MiB or less) partition with a vfat file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
===== Create an ESP =====<br />
If you do not have an ESP, you will need to create it. Follow [[UEFI#EFI System Partition]] for instructions on creating an ESP.<br />
<br />
== Installation ==<br />
{{Note|If you are performing an [[Installation guide|initial installation]] from the Arch live CD, make sure you have chrooted into the installed system before installing grub. Using the CD's own grub installation scripts may result in an invalid {{ic|grub.cfg}}, or other problems that will prevent the system from booting.}}<br />
<br />
=== BIOS systems ===<br />
GRUB can be [[pacman|installed]] with the {{Pkg|grub}} package from the [[official repositories]]. It will replace {{AUR|grub-legacy}} , if it is installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
There are 4 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to external USB stick|Install to external USB stick]] (for recovery)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
{{Note|The method is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to {{ic|/boot/grub}} and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). For partitionless disk (super-floppy) please refer to [[#Install to partition or partitionless disk]]}}<br />
<br />
To set up GRUB in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk (or BIOS Boot Partition in case of GPT partitioned disk, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk), run:<br />
<br />
# grub-install --target=i386-pc --recheck --debug /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
<br />
{{Note| {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to external USB stick =====<br />
Assume your USB stick's first partition is FAT32 and it's partition is /dev/sdy1<br />
<br />
# mkdir -p /tmp/y ; mount /dev/sdy1 /tmp/y <br />
# grub-install --target=i386-pc --recheck --debug --boot-directory=/tmp/y/boot /dev/sdy<br />
# grub-mkconfig -o /tmp/y/boot/grub/grub.cfg<br />
<br />
# optional, backup config files of grub.cfg<br />
# mkdir -p /tmp/y/etc/default<br />
# cp /etc/default/grub /tmp/y/etc/default<br />
# cp -a /etc/grub.d /tmp/y/etc<br />
<br />
# sync ; umount /tmp/y<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Note|GRUB does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the grub.cfg file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604. <br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partition (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel.<br />
<br />
=== UEFI systems ===<br />
{{Note|It is well known that different motherboard manufactures implement UEFI differently. Users experiencing problems getting GRUB or EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.}}<br />
<br />
First install the {{Pkg|grub}}, {{Pkg|dosfstools}}, and {{Pkg|efibootmgr}} packages, then follow the instructions below. (The last two packages are required for EFI support in grub.)<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB modules in the ESP. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
===== Recommended method =====<br />
{{Note|<br />
* The below commands assume you are using installing GRUB for {{ic|x86_64-efi}} (for {{ic|IA32-efi}} replace {{ic|x86_64-efi}} with {{ic|i386-efi}} in the below commands)<br />
* To do this, you need to be booted using UEFI and not BIOS, or grub-install will show errors.<br />
}}<br />
<br />
First, mount the ESP at your preferred mountpoint (usually {{ic|/boot/efi}}, hereafter referred to as $esp). On a first install, you will need to mkdir /boot/efi, if that's where you want to mount it.<br />
<br />
Now, install the GRUB UEFI application to {{ic|$esp/EFI/grub}} and its modules to {{ic|/boot/grub/x86_64-efi}}:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --recheck --debug<br />
<br />
{{Note|<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you have to "modprobe efivars", try [[Unified_Extensible_Firmware_Interface#Switch_to_efivarfs]].<br />
* When installing GRUB on a LVM system in a chroot environment (e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. {{ic|--bootloader-id}} specifies the name of the directory used to store the {{ic|grubx64.efi}} file.<br />
* If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB for BIOS systems. Any <device_path> provided will be ignored by the install script, as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
}}<br />
<br />
GRUB is now installed. Do not forget to [[#Generating main configuration file|generate the main configuration file]].<br />
<br />
===== Alternative method =====<br />
If you want to keep all of the GRUB boot files inside the EFI System Partition itself, add {{ic|--boot-directory&#61;$esp/EFI}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub --boot-directory=$esp/EFI --recheck --debug<br />
<br />
This puts the GRUB modules in {{ic|$esp/EFI/grub}}. ('/grub' is hard coded onto the end of this path.) Using this method, grub.cfg is kept on the EFI System Partition as well, so make sure you point grub-mkconfig to the right place in the configuration phase:<br />
<br />
# grub-mkconfig -o $esp/EFI/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB Standalone ====<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg ## use single quotes, ${cmdpath}/grub.cfg should be present as it is<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "$esp/EFI/grub/grubx64_standalone.efi" "boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
Then copy the GRUB config file to {{ic|$esp/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|$esp/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
{{Note|The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.}}<br />
<br />
{{Warning|You may find that the {{ic|grub.cfg}} file is not loaded due to {{ic|${cmdpath} }} missing a slash (i.e. {{ic|(hd1,msdos2)EFI/Boot}} instead of {{ic|(hd1,msdos2)/EFI/Boot}}) and so you are dropped into a GRUB shell. If this happens determine what {{ic|${cmdpath} }} is set to ({{ic|echo ${cmdpath} }}) and then load the config file manually (e.g. {{ic|configfile (hd1,msdos2)/EFI/Boot/grub.cfg}}).}}<br />
<br />
===== GRUB Standalone - Technical Info =====<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install. <br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}. <br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generating main configuration file ==<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}, this is covered in the [[#Basic configuration]] and [[#Advanced configuration]] sections.<br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or {{ic|/etc/grub.d/*}}.}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 here].<br />
* When generating the GRUB config file on a LVM system in a chroot environment (even ''arch-chroot'', e.g. during System installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. However, entries for other operating systems do not work out of the box. On BIOS systems, you may want to install {{Pkg|os-prober}}, which detects other operating systems installed on your machine and adds entries for them into {{ic|grub.cfg}}. If installed, it will be executed when running ''grub-mkconfig''. See [[#Dual-booting]] for advanced configuration.<br />
<br />
=== Converting GRUB Legacy's config file to the new format ===<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
== Basic configuration ==<br />
This section covers only editing the {{ic|/etc/default/grub}} configuration file. See [[#Advanced configuration]] if you need more.<br />
<br />
{{Note|Remember to always [[#Generating main configuration file|re-generate the main configuration file]] after you make changes to {{ic|/etc/default/grub}}.}}<br />
<br />
==== Additional arguments ====<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation. <br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}. <br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Visual configuration ===<br />
In GRUB it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB. This can be seen in the section [[#"No suitable mode found" error]]. This video mode is passed by GRUB to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
==== Setting the framebuffer resolution ====<br />
GRUB can set the framebuffer for both GRUB itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|<br />
* If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen<br />
* To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB prompt you can use the {{ic|1=vbeinfo}} command<br />
}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for example: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
==== 915resolution hack ====<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
First you need to find a video mode which will be modified later. For that we need the GRUB command shell:<br />
{{hc|sh:grub> 915resolution -l|<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
[...]<br />
'''Mode 30''' : 640x480, 8 bits/pixel<br />
[...]<br />
}}<br />
Next, we overwrite the {{ic|Mode 30}} with {{ic|1440x900}} resolution:<br />
{{hc|/etc/grub.d/00_header|<br />
[...]<br />
'''915resolution 30 1440 900 # Inserted line'''<br />
set gfxmode&#61;${GRUB_GFXMODE}<br />
[...]<br />
}}<br />
Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate {{ic|grub.cfg}} and reboot to test changes.<br />
<br />
==== Background image and bitmap fonts ====<br />
GRUB comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [[#Setting the framebuffer resolution|framebuffer resolution]].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct<br />
* The image is of the proper size and format (tga, png, 8-bit jpg)<br />
* The image was saved in the RGB mode, and is not indexed<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file<br />
<br />
==== Theme ====<br />
Here is an example for configuring Starfield theme which was included in GRUB package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
[[#Generating main configuration file|Re-generate]] {{ic|grub.cfg}} to apply the changes. If configuring the theme was successful, you will see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
==== Menu colors ====<br />
You can set the menu colors in GRUB. The available colors for GRUB can be found in [https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html the GRUB Manual].<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
==== Hidden menu ====<br />
One of the unique features of GRUB is hiding/skipping the menu and showing it by holding {{ic|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_TIMEOUT=0<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
GRUB_HIDDEN_TIMEOUT is how many seconds before displaying menu. You also need to set GRUB_TIMEOUT=0 if you want to hide menu.<br />
<br />
==== Disable framebuffer ====<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
Another option if you want to keep the framebuffer in GRUB is to revert to text mode just before starting the kernel. To do that modify the variable in {{ic|/etc/default/grub}}:<br />
GRUB_GFXPAYLOAD_LINUX=text<br />
<br />
=== Persistent block device naming ===<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via file system UUIDs are used by default in GRUB. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant file system is resized or recreated. Remember this when modifying partitions & file systems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Recall previous entry ===<br />
GRUB can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that GRUB will default to the saved entry. To enable saving the selected entry, add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, e.g. Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}, will need {{ic|savedefault}} added.}}<br />
<br />
=== Changing the default menu entry ===<br />
To change the default selected entry, edit {{ic|/etc/default/grub}} and change the value of {{ic|GRUB_DEFAULT}}:<br />
<br />
Using numbers :<br />
GRUB_DEFAULT=0<br />
Grub identifies entries in generated menu counted from zero. That means 0 for the first entry which is the default value, 1 for the second and so on.<br />
<br />
Or using menu titles :<br />
GRUB_DEFAULT='Arch Linux, with Linux core repo kernel'<br />
<br />
=== Disable Submenu ===<br />
If you have multiple kernels installed, say linux and linux-lts, by default {{ic|grub-mkconfig}} groups them in a submenu. <br />
If you do not like this behaviour you can go back to one single menu by adding the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_DISABLE_SUBMENU=y<br />
<br />
=== Root encryption ===<br />
<br />
To let GRUB automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
See [[Dm-crypt/System Configuration#Boot loader]] for more details.<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
{{Accuracy|1=The following step was added with [https://wiki.archlinux.org/index.php?title=GRUB&diff=184194&oldid=183020], but there is not a clear reason to disable the usage of UUIDs for the root file system.}}<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
=== Boot non-default entry only once ===<br />
The command {{ic|grub-reboot}} is very helpful to boot another entry than the default only once. GRUB loads the entry passed in the first command line argument, when the system is rebooted the next time. Most importantly GRUB returns to loading the default entry for all future booting. Changing the configuration file or selecting an entry in the GRUB menu is not necessary.<br />
{{Note|This requires {{ic|1=GRUB_DEFAULT=saved}} in {{ic|/etc/default/grub}} (and then regenerating {{ic|grub.cfg}}) or, in case of hand-made {{ic|grub.cfg}}, the line {{ic|1=set default="${saved_entry}"}}.}}<br />
<br />
== Advanced configuration ==<br />
This section covers manual editing of {{ic|grub.cfg}}, writing custom scripts in {{ic|/etc/grub.d/}} and other advanced settings.<br />
<br />
=== Manually creating grub.cfg ===<br />
{{Warning|Editing this file is strongly discouraged. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} directory.}}<br />
<br />
A basic GRUB config file uses the following options:<br />
* {{ic|(hd''X'',''Y'')}} is the partition ''Y'' on disk ''X'', partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=''N''}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=''M''}} is the time ''M'' to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|1=set root=(hd''X'',''Y'')}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
# Config file for GRUB - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
# set root=(hd0,3)<br />
# chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
{{Tip|If you want GRUB to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Automatically generating using /etc/grub.d/40_custom and grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode (as per alternate method):<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
For example, a typical {{ic|/etc/grub.d/40_custom}} file, could appear similar to the following one, created for [http://h10025.www1.hp.com/ewfrf/wc/product?cc=us&destPage=product&lc=en&product=5402703&tmp_docname= HP Pavilion 15-e056sl Notebook PC], originally with Microsoft Windows 8 preinstalled. Each {{ic|menuentry}} should mantain a structure similar to the following ones. Note that the UEFI partition {{ic|/dev/sda2}} within GRUB is called {{ic|hd0,gpt2}} and {{ic|ahci0,gpt2}} (see [[#Windows Installed in UEFI-GPT Mode menu entry|here]] for more info).<br />
<br />
{{hc|/etc/grub.d/40_custom|<nowiki>#!/bin/sh<br />
exec tail -n +3 $0<br />
# This file provides an easy way to add custom menu entries.&nbsp; Simply type the<br />
# menu entries you want to add after this comment.&nbsp; Be careful not to change<br />
# the 'exec tail' line above.<br />
<br />
menuentry "HP / Microsoft Windows 8.1" {<br />
echo "Loading HP / Microsoft Windows 8.1..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "HP / Microsoft Control Center" {<br />
echo "Loading HP / Microsoft Control Center..."<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 763A-9CB6<br />
chainloader /EFI/HP/boot/bootmgfw.efi<br />
}<br />
<br />
menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}<br />
<br />
menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
{{bc|<nowiki>menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
===== Windows XP menu entry=====<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|sda3}}.<br />
<br />
{{bc|<nowiki># (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root="(hd0,3)"<br />
chainloader +1<br />
}</nowiki>}}<br />
<br />
If the Windows bootloader is on an entirely different hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<br />
<br />
{{bc|drivemap -s hd0 hd2}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the uefi bitness. It '''WILL NOT WORK''' in bios installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations|this]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations|this]] for more info.}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands. {{ic|$fs_uuid}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28</nowiki>}}<br />
<br />
{{ic|$hints_string}}'s command:<br />
<br />
{{bc|<nowiki># grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1</nowiki>}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== "Shutdown" menu entry =====<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually C:). In {{ic|blkid}} output, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
{{Note|These menuentries will work only in Legacy BIOS boot mode. It WILL NOT WORK in uefi installed grub(2). See [[Windows_and_Arch_Dual_Boot#Windows_UEFI_vs_BIOS_limitations]] and [[Windows_and_Arch_Dual_Boot#Bootloader_UEFI_vs_BIOS_limitations]].}}<br />
<br />
For Windows Vista/7/8/8.1:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
{{Note|In some cases, mine I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
{{Merge|NeoGRUB|New page has been created, so this section should be merged there.}}<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB menu format, chainload to it by replacing the contents of your {{ic|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/i386-pc/core.img<br />
<br />
Finally, recreate your {{ic|grub.cfg}} using {{ic|grub-mkconfig}}.<br />
<br />
=== Booting ISO9660 image file directly via GRUB ===<br />
{{Poor writing|The only boxes used should be code blocks, otherwise the section will be unreadable. Anything else should be plain text.}}<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO image file and update the boot menu accordingly, for example:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Here are some examples about booting different distributions' LiveCD.<br />
{{Note|<br />
* The following examples assume the ISO image exists at {{ic|/boot/iso}} on {{ic|hd1,2}}(i.e.{{ic|/dev/sdb2}}).<br />
* Not all distributions' ISO image can boot that way (e.g. CentOS ≤ 6.5), so when you try to boot other distribution's ISO which is or not listed here and it is stuck, please looking for related documentation and wiki pages or ask for help in the related community.}}<br />
{{tip|The prefix {{ic|'''(hd1,2)'''}} before {{ic|$isofile}}(also {{ic|$initrdfile}} and any other similar) can be omitted when the grub directory(the directory includes GRUB config files and modules, e.g. {{ic|/boot/grub}}) and the ISO images are in the same partition. This is recommended for thumbdrives.}}<br />
<br />
==== Arch Linux ====<br />
{{Tip|If you want to boot into a 32-bit system, replace {{ic|x86_64}} with {{ic|i686}}.}}<br />
===== monthly release =====<br />
{{bc|1=menuentry '[loopback]archlinux-2014.08.01-dual.iso' {<br />
set isofile='/boot/iso/archlinux-2014.08.01-dual.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/arch/boot/'''x86_64'''/vmlinuz archisolabel=ARCH_'''201408''' img_dev='''/dev/sdb2''' img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/'''x86_64'''/archiso.img<br />
}<br />
}}<br />
{{note|<br />
* It's recommend for thumbdrives to use [[Persistent block device naming|a persistent name]] instead of {{ic|/dev/sd'''''xY'''''}} for the {{ic|img_dev}} parameter, e.g. {{ic|1=img_dev=/dev/disk/by-label/MYUSBSTICK}} (or {{ic|1=img_label=MYUSBSTICK}}).<br />
* As the official monthly release build script [https://projects.archlinux.org/archiso.git/tree/configs/releng/build.sh#n6 defines], you need to edit the label string after {{ic|1=archisolabel=}} when you use a newer monthly released ISO image.<br />
* For a complete list of archiso boot parameters, please see its [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams documentation].}}<br />
<br />
===== archboot =====<br />
See also: [[Archboot]]<br />
{{bc|1=<br />
menuentry '[loopback]archlinux-2014.08-1-archboot' {<br />
set isofile='/boot/iso/archlinux-2014.08-1-archboot.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/boot/vmlinuz_'''x86_64''' iso_loop_dev='''/dev/sdb2''' iso_loop_path=$isofile<br />
initrd (loop)/boot/initramfs_'''x86_64'''.img<br />
}<br />
}}<br />
<br />
==== CentOS ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-DVD' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-DVD.iso'<br />
loopback '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|The boot parameter {{ic|1=inst.stage2=hd:}} which is used by [https://fedoraproject.org/wiki/Anaconda anaconda], is similar to [[fstab]]'s first field(fs_spec):<br />
* {{ic|1=inst.stage2=hd:/dev/sd'''''xY'''''}}<br />
* {{ic|1=inst.stage2=hd:LABEL=MYUSBSTICK}}<br />
* {{ic|1=inst.stage2=hd:UUID=00000000-0000-0000-0000-0000deadbeef}}<br />
}}<br />
<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]CentOS-7.0-1406-x86_64-GnomeLive' {<br />
set isofile='/boot/iso/CentOS-7.0-1406-x86_64-GnomeLive.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=CentOS-7-live-GNOME-x86_64 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Debian ====<br />
===== Stock install medium =====<br />
{{note|To install debian from any stock install medium on a hard disk(or usb stick), it's necessary to use a different initramfs instead of the default one on the installation medium(it is located at {{ic|(loop)/install.amd/initrd.gz}}). If you boot with the default one, the [https://www.debian.org/devel/debian-installer/ debian-installer] will unable to find or mount the proper iso image for installation. Please download the initramfs for hard disk installation from [https://mirrors.kernel.org/debian/dists/stable/main/installer-amd64/current/images/hd-media/initrd.gz an official mirror site], put it in the same directory with the image file and give it a suitable name({{ic|debian-7.6.0-amd64-DVD-1.hdd.initrd.gz}} in this example).}}<br />
{{bc|1=menuentry '[loopback]debian-7.6.0-amd64-DVD-1' {<br />
set isofile='/boot/iso/debian-7.6.0-amd64-DVD-1.iso'<br />
set initrdfile='/boot/iso/debian-7.6.0-amd64-DVD-1.hdd.initrd.gz'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/install.amd/vmlinuz vga=791 iso-scan/ask_second_pass=true iso-scan/filename=$isofile<br />
initrd '''(hd1,2)'''$initrdfile<br />
}<br />
}}<br />
===== Live install medium =====<br />
{{bc|1=menuentry '[loopback]debian-live-7.6.0-amd64-xfce-desktop' {<br />
set isofile='/boot/iso/debian-live-7.6.0-amd64-xfce-desktop.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live config fromiso='''/dev/sdb2'''/$isofile<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
{{note|It's also OK to use {{ic|1=findiso=$isofile}} instead of the longer {{ic|1=fromiso=/dev/disk/by-.../.../$isofile}}. Anyway, using {{ic|1=fromiso=}} instead of {{ic|1=findiso=}} may speed up the initialization progress because it avoids unnecessary mounting.}}<br />
<br />
==== Fedora ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-20-x86_64-DVD' {<br />
set isofile='/boot/iso/Fedora-20-x86_64-DVD.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz noeject inst.stage2=hd:'''/dev/sdb2''':/$isofile<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
{{tip|For a list of [https://fedoraproject.org/wiki/Anaconda anaconda] boot parameters, please see this [https://git.fedorahosted.org/cgit/anaconda.git/tree/docs/boot-options.txt documentation].}}<br />
===== Desktop live medium =====<br />
{{bc|1=menuentry '[loopback]Fedora-Live-Desktop-x86_64-20-1' {<br />
set isofile='/boot/iso/Fedora-Live-Desktop-x86_64-20-1.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/isolinux/vmlinuz0 root=live:CDLABEL=Fedora-Live-Desktop-x86_64-20-1 iso-scan/filename=$isofile rd.live.image<br />
initrd (loop)/isolinux/initrd0.img<br />
}<br />
}}<br />
<br />
==== Kali Linux ====<br />
{{bc|1=menuentry '[loopback]kali-linux-1.0.7-amd64' {<br />
set isofile='/boot/iso/kali-linux-1.0.7-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/live/vmlinuz boot=live findiso=$isofile noconfig=sudo username=root hostname=kali<br />
initrd (loop)/live/initrd.img<br />
}<br />
}}<br />
<br />
==== openSUSE ====<br />
===== Stock installation medium =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-DVD-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-DVD-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux install=hd:$isofile<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
===== LiveCD =====<br />
{{bc|1=menuentry '[loopback]openSUSE-13.1-KDE-Live-x86_64' {<br />
set isofile='/boot/iso/openSUSE-13.1-KDE-Live-x86_64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/x86_64/loader/linux isofrom_device='''/dev/sdb2''' isofrom_system=$isofile LANG='''en_US.UTF-8'''<br />
initrd (loop)/boot/x86_64/loader/initrd<br />
}<br />
}}<br />
<br />
==== Sabayon ====<br />
{{bc|1=<br />
menuentry '[loopback]Sabayon_Linux_14.05_amd64_KDE' {<br />
set isofile='/boot/iso/Sabayon_Linux_14.05_amd64_KDE.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/boot/sabayon root=/dev/ram0 aufs cdroot locale='''en_US''' loop=/livecd.squashfs looptype=squashfs isoboot=$isofile<br />
initrd (loop)/boot/sabayon.igz<br />
}<br />
}}<br />
<br />
==== Slackware Linux ====<br />
{{bc|1=menuentry '[loopback]slackware64-14.1-install-dvd' {<br />
set isofile='/boot/iso/slackware64-14.1-install-dvd.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/kernels/huge.s/bzImage printk.time=0<br />
initrd (loop)/isolinux/initrd.img<br />
}<br />
}}<br />
<br />
==== Ubuntu ====<br />
{{bc|1=menuentry '[loopback]ubuntu-14.04-desktop-amd64' {<br />
set isofile='/boot/iso/ubuntu-14.04-desktop-amd64.iso'<br />
loopback loop '''(hd1,2)'''$isofile<br />
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile locale='''en_US.UTF-8'''<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
}}<br />
<br />
=== LVM ===<br />
If you use [[LVM]] for your {{ic|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
=== RAID ===<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# grub-install --target=i386-pc --recheck --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
=== Using labels ===<br />
It is possible to use labels, human-readable strings attached to file systems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L ''LABEL'' ''PARTITION''<br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.img<br />
}<br />
<br />
=== Password protection of GRUB menu ===<br />
If you want to secure GRUB so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it:<br />
<br />
{{hc|grub-mkpasswd-pbkdf2|<br />
[...]<br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A<br />
}}<br />
<br />
Then, add the following to {{ic|/etc/grub.d/40_custom}}:<br />
<br />
{{hc|/etc/grub.d/40_custom|<br />
cat << EOF<br />
<br />
set superusers<nowiki>=</nowiki>"'''username'''"<br />
password_pbkdf2 '''username''' '''<password>'''<br />
<br />
EOF<br />
}}<br />
<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
=== Hide GRUB unless the Shift key is held down ===<br />
In order to achieve the fastest possible boot, instead of having GRUB wait for a timeout, it is possible for GRUB to hide the menu, unless the {{ic|Shift}} key is held down during GRUB's start-up.<br />
<br />
In order to achieve this, you should add the following line to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_FORCE_HIDDEN_MENU="true"<br />
<br />
And the following file should be created and made executable:<br />
<br />
{{hc|/etc/grub.d/31_hold_shift|<nowiki><br />
#! /bin/sh<br />
set -e<br />
<br />
# grub-mkconfig helper script.<br />
# Copyright (C) 2006,2007,2008,2009 Free Software Foundation, Inc.<br />
#<br />
# GRUB is free software: you can redistribute it and/or modify<br />
# it under the terms of the GNU General Public License as published by<br />
# the Free Software Foundation, either version 3 of the License, or<br />
# (at your option) any later version.<br />
#<br />
# GRUB is distributed in the hope that it will be useful,<br />
# but WITHOUT ANY WARRANTY; without even the implied warranty of<br />
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the<br />
# GNU General Public License for more details.<br />
#<br />
# You should have received a copy of the GNU General Public License<br />
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.<br />
<br />
prefix="/usr"<br />
exec_prefix="${prefix}"<br />
datarootdir="${prefix}/share"<br />
<br />
export TEXTDOMAIN=grub<br />
export TEXTDOMAINDIR="${datarootdir}/locale"<br />
source "${datarootdir}/grub/grub-mkconfig_lib"<br />
<br />
found_other_os=<br />
<br />
make_timeout () {<br />
<br />
if [ "x${GRUB_FORCE_HIDDEN_MENU}" = "xtrue" ] ; then <br />
if [ "x${1}" != "x" ] ; then<br />
if [ "x${GRUB_HIDDEN_TIMEOUT_QUIET}" = "xtrue" ] ; then<br />
verbose=<br />
else<br />
verbose=" --verbose"<br />
fi<br />
<br />
if [ "x${1}" = "x0" ] ; then<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
else<br />
cat << EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if sleep$verbose --interruptible ${GRUB_HIDDEN_TIMEOUT} ; then<br />
set timeout=0<br />
fi<br />
fi<br />
EOF<br />
fi<br />
fi<br />
fi<br />
}<br />
<br />
adjust_timeout () {<br />
if [ "x$GRUB_BUTTON_CMOS_ADDRESS" != "x" ]; then<br />
cat <<EOF<br />
if cmostest $GRUB_BUTTON_CMOS_ADDRESS ; then<br />
EOF<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT_BUTTON}" "${GRUB_TIMEOUT_BUTTON}"<br />
echo else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
echo fi<br />
else<br />
make_timeout "${GRUB_HIDDEN_TIMEOUT}" "${GRUB_TIMEOUT}"<br />
fi<br />
}<br />
<br />
adjust_timeout<br />
<br />
cat <<EOF<br />
if [ "x\${timeout}" != "x-1" ]; then<br />
if keystatus; then<br />
if keystatus --shift; then<br />
set timeout=-1<br />
else<br />
set timeout=0<br />
fi<br />
else<br />
if sleep$verbose --interruptible 3 ; then<br />
set timeout=0<br />
fi<br />
fi<br />
fi<br />
EOF<br />
</nowiki>}}<br />
<br />
Make that file executable and then regenerate your grub config:<br />
chmod a+x /etc/grub.d/31_hold_shift<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Combining the use of UUIDs and basic scripting ===<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs for your system. The example applies to a system with a boot and root partition. You will obviously need to modify the GRUB configuration if you have additional partitions:<br />
<br />
{{bc|<nowiki><br />
menuentry "Arch Linux 64" {<br />
# Set the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid $the_root_uuid --set=root<br />
search --fs-uuid $the_boot_uuid --set=grub_boot<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid ] ; then<br />
set grub_boot=($grub_boot)/boot<br />
else<br />
set grub_boot=($grub_boot)<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux $grub_boot/vmlinuz-linux root=/dev/disk/by-uuid/$the_root_uuid ro<br />
initrd $grub_boot/initramfs-linux.img<br />
}<br />
</nowiki>}}<br />
<br />
== Using the command shell ==<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
grub> <br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition.<br />
<br />
==== Chainloading a partition ====<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk, <br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
See the examples in [[Grub#Using_the_rescue_console|#Using_the_rescue_console]]<br />
<br />
== GUI configuration tools ==<br />
Following package may be installed:<br />
* {{App|grub-customizer|Customize the bootloader (GRUB or BURG)|https://launchpad.net/grub-customizer|{{AUR|grub-customizer}}}}<br />
* {{App|grub2-editor|KDE4 control module for configuring the GRUB bootloader|http://kde-apps.org/content/show.php?content&#61;139643|{{AUR|grub2-editor}}}}<br />
* {{App|startupmanager|GUI app for changing the settings of GRUB Legacy, GRUB, Usplash and Splashy ([https://launchpad.net/startup-manager/+announcement/8300 abandonned])|http://sourceforge.net/projects/startup-manager/|{{AUR|startupmanager}}}}<br />
<br />
== parttool for hide/unhide ==<br />
If you have a Windows 9x paradigm with hidden {{ic|C:\}} disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third {{ic|C:\}} disk of three Windows 9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Advanced configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== GRUB UEFI drops to shell ===<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== GRUB UEFI not loaded ===<br />
An example of a working EFI:<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
* Move GRUB v2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
=== Arch not found from other OS ===<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
== See also ==<br />
# Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
# GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
# http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html - quite complete description of how to configure GRUB</div>Bwidhttps://wiki.archlinux.org/index.php?title=Help_talk:Writing_article_introductions&diff=333638Help talk:Writing article introductions2014-09-03T13:56:15Z<p>Bwid: </p>
<hr />
<div>==Programming Languages - Introductory Paragraph==<br />
I was looking at the [[Python]] article, and noticed it has a quite verbose description of what Python is, copied from Wikipedia. I would prefer shorter description, which still captures the essentials. In the concrete example, i would pick the first paragraph from [https://docs.python.org/3/tutorial/ python tutorial].<br />
Looking at other articles for Programming Languages, i have noticed an inconsistency. [[D_(programming_language)]] uses the same style (quoting Wikipedia) and [[Java]] also quotes Wikipedia but using a different format. [[Go]], [[Haskell]], [[PHP]] just have a short intro which links to the Language Homepage.This was also the case on the Python article, it was changed there on 2014-07-23.<br />
Would it be a good idea to agree on a common style? Or am i just making a fuss about an unimportant issue?<br />
[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 13:56, 3 September 2014 (UTC)</div>Bwidhttps://wiki.archlinux.org/index.php?title=Help_talk:Writing_article_introductions&diff=333637Help talk:Writing article introductions2014-09-03T13:55:27Z<p>Bwid: Programming Languages - Introductory Paragraph</p>
<hr />
<div>==Programming Languages - Introductory Paragraph==<br />
I was looking at the [[Python]] article, and noticed it has a quite verbose description of what Python is, copied from Wikipedia. I would prefer shorter description, which still captures the essentials. In the concrete example, i would pick the first paragraph from [https://docs.python.org/3/tutorial/ python tutorial].<br />
Looking at other articles for Programming Languages, i have noticed an inconsistency. [[D_(programming_language)]] uses the same style (quoting Wikipedia) and [[Java]] also quotes Wikipedia but using a different format. [[Go]], [[Haskell]], [[PHP]] just have a short intro which links to the Language Homepage.This was also the case on the Python article, it was changed there on 2014-07-23.<br />
Would it be a good idea to agree on a common style? Or am i just making a fuss about an unimportant issue?</div>Bwidhttps://wiki.archlinux.org/index.php?title=Help_talk:Style&diff=333636Help talk:Style2014-09-03T13:54:27Z<p>Bwid: i will move this to Help:Writing_article_introductions Discussion</p>
<hr />
<div>==Read this first==<br />
[[Help:Style]] is an official document of the ArchWiki, and it is actively monitored for malicious, unapproved, or poor quality edits. This is necessary to ensure sufficient stability over time, since frequent, undiscussed changes to its rules would defeat the purpose of the guide itself.<br />
<br />
It is probably needless to say that the active supervision of the article makes this very talk page the most important and effective place for discussing every possible improvement to the guide, from the correction of small typos to major changes like the introduction of new rules. Every report or discussion is welcome and will be answered as soon as possible. However, if an existing style rule is under dispute, its current state remains enforced until it is changed, if that ever happens.<br />
<br />
This guide was born after several months of discussions among the administrators and the most active contributors at the time, and it is a compromise among their ideas and those of who has been contributing until now. While new ideas and proposals that are coherent with the guide will probably be accepted and implemented, it is also likely that the requests that aim to radically change the way a particular style issue is already addressed will be discarded. We all must acknowledge the fact that it is reasonably unrealistic to think that all the ArchWiki users will ever completely agree over all the style rules, that is why it becomes necessary that final decisions be made by the administrators: we hope that this concept will be peacefully accepted by everybody, so that we can all collaborate in a more constructive way.<br />
<br />
Thank you for reading this notice and for contributing to the ArchWiki! -- [[ArchWiki:Administrators|The ArchWiki Administrators]] 21:27, 14 January 2012 (EST)<br />
<br />
{{Tip|A way to speed up the addition or modification of style rules is to provide some text that, if approved, can be directly copy-pasted in the guide, just like patches work for bug reports.}}<br />
__TOC__<br />
== Change Edit Summary label and possibility to make it mandatory ==<br />
<br />
All edits to articles should be accompanied by some words in the summary filed, answering the question "'''Why''' did you edit the article?". "What", "where", "when" and "how" are self-explained by the diff itself, it's redundant to add them. An explanation is not mandatory in talk pages, where the "why" should be already evident. Remember that links are allowed in the summary field, so it is allowed to point to an existing discussion. -- [[User:Kynikos|Kynikos]] 09:32, 3 May 2011 (EDT)<br />
<br />
Maybe we could submit a bug to request the change of the word "Summary:" to "Reason for editing:" next to the input in the edit page itself? -- [[User:Kynikos|Kynikos]] 11:33, 3 May 2011 (EDT)<br />
:+1<br />
:Would it go directly upstream? The Polish wiki has something like ''Summarize the changes [you've made to the article]''. Wikipedia has ''Edit summary <sub>(Briefly describe the changes you have made)</sub>''. They all deal with what is being changed, not '''why''' - we need to fix this :-) -- [[User:Karol|Karol]] 12:04, 3 May 2011 (EDT)<br />
::Done: {{Bug|24075}}, remember you can vote it. -- [[User:Kynikos|Kynikos]] 12:57, 3 May 2011 (EDT)<br />
:::Any wiki admin can change this message (aside: can you view [[Special:AllMessages]]?) I think it might be more fitting to include this as an addendum to the copyright notice instead (text above the summary field). Perhaps we should also consider making the edit summary mandatory (i.e. prevent saving with a blank summary). -- [[User:Pointone|pointone]] 22:55, 4 May 2011 (EDT)<br />
::::Nice, I can see that page, I didn't know that ^^ Maybe I should close the bug request then. Anyway I'm quite sure that ''only'' appending this recommendation to the copyright notice would make people start ignoring it very soon (as it happens with road signs eheh): I'm still in favour of changing the word "Summary", as it's misleading. Making the field mandatory could be a great idea instead, but for what I've seen until now, if the edit page returns an error, it forgets about the editing done, and it would be quite annoying (the textarea could be easily repopulated echoing $_POST['...'] instead of recovering the text back from the database; I have only tested this when trying to edit a page that has been edited by somebody else meanwhile). -- [[User:Kynikos|Kynikos]] 06:15, 5 May 2011 (EDT)<br />
::::(Well, doing it in javascript would solve the problem, though using JS is not very wiki-style it seems) -- [[User:Kynikos|Kynikos]] 06:17, 5 May 2011 (EDT)<br />
:::::When saving an edit that conflicts with another, your changes ''are'' saved. MediaWiki presents you with two text areas: one contains the page contents and the other contains your edit.<br />
:::::Either way, a quick Google search reveals [http://commons.wikimedia.org/wiki/User:DieBuche/forcesummary.js User:DieBuche/forcesummary.js] and [[Wikipedia:Wikipedia:WikiProject User scripts/Scripts/Force edit summary]] as two possible solutions. There also is a user preference option under '''Editing''' > '''Advanced options''' > '''Prompt me when entering a blank edit summary''' -- I wonder whether we can enable this option by default as a less-intrusive solution.<br />
:::::-- [[User:Pointone|pointone]] 09:16, 5 May 2011 (EDT)<br />
::::::Uhm it always looked like I lost my changes everytime I had edit conflicts (always easily recovered with the back button), anyway it could be that I didn't look well.<br />
::::::About the main topic, I would first try just to change the Summary text, anyway if you want to go the JS way immediately, do it in a way that the user understands that he has to answer the question "why", not "what", otherwise all edit summaries would probably be filled with "added section", "corrected code", "deleted section" and so on (well, those ''are'' summaries in the end, and that's what the form requests literally atm). -- [[User:Kynikos|Kynikos]] 11:07, 5 May 2011 (EDT)<br />
:::::::I think it's also OK to combine 'what' with 'why' e.g. '[https://wiki.archlinux.org/index.php?title=Arch_Based_Distributions_(Active)&diff=prev&oldid=139695 removed '''outdated''' links]'. I'm not a native English speaker, but it sounds more natural than 'links were outdated'. -- [[User:Karol|Karol]] 11:50, 6 May 2011 (EDT)<br />
::::::::Of course it's also ok, anyway I'm not a native speaker either, but if a label says "Reason for editing" it comes more natural to me to write "links were outdated". This system should also exploit a bit of psychology afterall. -- [[User:Kynikos|Kynikos]] 12:56, 6 May 2011 (EDT)<br />
:::::::::<facepalm> Of course you are absolutely right ... I - ummm - forgot that we wanted to change 'Summary' to 'Reason for editing'. Sorry about that. -- [[User:Karol|Karol]] 19:58, 8 May 2011 (EDT)<br />
:::Since the bug got closed as 'Upstream', do we go upstream with this? -- [[User:Karol|Karol]] 19:58, 8 May 2011 (EDT)<br />
::::I am curious whether this has been discussed upstream already... I have no problem with making the change on our end, since every wiki handles summary policy differently (as pointed-out above in examples). -- [[User:Pointone|pointone]] 22:46, 8 May 2011 (EDT)<br />
:::::Well you are the one in charge here, you can decide what to do now ;) -- [[User:Kynikos|Kynikos]] 05:53, 9 May 2011 (EDT)<br />
::::::The style part of this discussion has been implemented in the guide. I'd still be interested in changing "Summary" to "Reason for editing", anybody else? -- [[User:Kynikos|Kynikos]] 15:32, 21 September 2011 (EDT)<br />
:::::::Going upstream would benefit more that just our wiki, as mediawiki is a pretty popular piece of software. +1 from me. -- [[User:Karol|Karol]] 16:45, 21 September 2011 (EDT)<br />
::::::::The relevant system message is [[MediaWiki:Summary]]. I would suggest that the word "Summary" itself remain, as it is referenced in other locations and the documentation. My vote is for addition of an explanatory subtext à la Wikipedia. (Summary: <sub>(Briefly describe the changes you have made)</sub>). -- [[User:Pointone|pointone]] 13:50, 22 September 2011 (EDT)<br />
:::::::::Cooool, that's the way to go! +1000 XD<br />
:::::::::Some ideas:<br />
:::::::::*<sub>Briefly explain the reason for the changes you have made</sub><br />
:::::::::*<sub>Briefly explain the reason for your edit</sub><br />
:::::::::*<sub>Briefly explain the reason for your changes</sub><br />
:::::::::*<sub>Briefly explain the reason why you edited the page</sub><br />
:::::::::-- [[User:Kynikos|Kynikos]] 15:55, 22 September 2011 (EDT)<br />
::::::::::I think a combination of using explanatory text (I like something such as "<sub>Briefly explain the reason for your changes</sub>" from your suggestions), and investigating how to set "Prompt me when entering a blank edit summary" user option by default would make it more noticeable and be a great start here. [[User:Emiralle|Emiralle]] 12:56, 15 October 2011 (EDT)<br />
:::::::::::I'd like to make the edit summary strictly mandatory (meaning that a blank summary field won't allow submitting the edit): pointone mentioned some possible methods for doing this in the first part of the discussion, I'm just adding some more references as reminders (don't know exactly what to do with them yet... :P ): [http://www.mediawiki.org/wiki/Manual:$wgDefaultUserOptions] (see "forceeditsummary"), [http://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#Optional_additional_data], [http://www.mediawiki.org/wiki/Wikia_code/includes/EditPage.php]. -- [[User:Kynikos|Kynikos]] 15:01, 20 October 2011 (EDT)<br />
::::::::::::For the moment I've changed the label to:<br />
:::::::::::::[[Help:Style#Edit summary|'''Summary''']] <small>('''what''' you did and '''why''')</small>:<br />
::::::::::::as you can see when opening a page for edit, I hope it's ugly and annoying enough to be noticed by many >;)<br />
::::::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:37, 11 July 2013 (UTC)<br />
:::::::::::::The edit box has been moved to the right, so it's easy to spot that something's different. I like it, good job, Kynikos. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 19:14, 12 July 2013 (UTC)<br />
:::About making the ''Prompt me when entering a blank edit summary'' option enabled by default, this is what has to be done:<br />
:::# Have {{Bug|35545}} implemented<br />
:::# Edit [[MediaWiki:Missingsummary]] and make it more visible and formative<br />
:::# Add the {{ic|forceeditsummary}} option to the default user preferences as described in [[mw:Manual:$wgDefaultUserOptions]]<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:06, 13 July 2013 (UTC)<br />
<br />
==Article summary templates==<br />
See [[Help talk:Style/Article summary templates]].<br />
<br />
== Visited links color ==<br />
<br />
''[This sub-discussion stemmed as one of the several replies to [[#Style vs. Usability]]. Note that you may find some references to other sub-discussions that have been closed and removed. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:32, 27 July 2013 (UTC)]''<br />
<br />
Changing the color of visited links has been in my todo list for some time, maybe it's time to submit a bug for that: I'd like to see a purplish color, I tried something like <span style="color:#606;">#606</span>, <span style="color:#70b;">#70b</span>, <span style="color:#74b;">#74b</span>. More ideas? Objections?<br />
<br />
-- [[User:Kynikos|Kynikos]] 08:33, 19 January 2012 (EST)<br />
<br />
Note that interwiki links already become purple (albeit still too greyish?) when visited: [[wikipedia:Main Page]] '''[[wikipedia:Main Page]]'''. -- [[User:Kynikos|Kynikos]] 15:25, 24 January 2012 (EST)<br />
<br />
I'd also like to request that links remain bold even when they are in indented paragraphs ({{ic|#bodyContent dd > a {font-weight:bold;} }}?) -- [[User:Kynikos|Kynikos]] 11:46, 29 January 2012 (EST)<br />
<br />
:Completely agree. Also, I think, color should be different from one of interwiki links. --[[User:AlexanderR|AlexanderR]] 23:54, 29 January 2012 (EST)<br />
<br />
::Do you mean of a completely different color? Can you be more specific or give an example? In any case if there should be a difference in color among links, it should distinguish internal from external links (including interwiki).<br />
::However I think that black for normal text, blue for links (internal or external), purple for visited links and black on cyan for code may be already enough.<br />
::-- [[User:Kynikos|Kynikos]] 07:11, 31 January 2012 (EST)<br />
<br />
:::>> Do you mean of a completely different color?<br />
:::No, a bit darker shade than <span style="color:#606;">#606</span> (or, maybe even a bit more rich) would be perfect. --[[User:AlexanderR|AlexanderR]] 00:29, 4 February 2012 (EST)<br />
<br />
== Pkg and AUR templates: add icon, make them look different ==<br />
<br />
''[This sub-discussion stemmed as one of the several replies to [[#Style vs. Usability]]. Note that you may find some references to other sub-discussions that have been closed and removed. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:32, 27 July 2013 (UTC)]''<br />
<br />
More about visibility: we could <u>evaluate</u> (which means I'm not supporting yet this idea, i.e. I'm brainstorming) the possibility of adding a little inline package icon at the end of [[Template:Pkg]] and [[Template:AUR]] in a similar fashion to what happens with regular external links, that get a little arrow. Thoughts?<br />
<br />
I'm strongly against indentation as it won't work with installation requests that are included in longer sentences.<br />
<br />
-- [[User:Kynikos|Kynikos]] 08:33, 19 January 2012 (EST)<br />
<br />
If the icon for official packages is different from the one for aur packages, this may also let us avoid always adding "available in the [[official repositories]]" and "available in the [[AUR]]". -- [[User:Kynikos|Kynikos]] 11:46, 29 January 2012 (EST)<br />
<br />
:Well, if you find suitable icons. --[[User:AlexanderR|AlexanderR]] 23:54, 29 January 2012 (EST)<br />
:'''Edit:''' and develop alternative presentation for text browsers --[[User:AlexanderR|AlexanderR]] 23:54, 29 January 2012 (EST)<br />
<br />
::As an alternative to images, something like {{AUR|package}}<sup><small>[[AUR]]</small></sup> could be used. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:43, 24 July 2013 (UTC)<br />
<br />
:::We should also discuss, whether to change only AUR template, or also Pkg template. If we use {{AUR|package}}<sup><small>[[AUR]]</small></sup> style, I think it would be OK to let Pkg as is, but it would not allow to avoid "available in the [[official repositories]]". Adding "[[official repositories]]" into superscript for Pkg template is not possible because it's too long, perhaps some abbreviation could be introduced for this purpose.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:31, 24 July 2013 (UTC)<br />
<br />
::::The wording "available in the [[official repositories]]" was practically required only for consistency with the "available in the [[AUR]]" wording, but a link to [[official repositories]] is already in [[pacman]], and [[official repositories]] doesn't contain any useful information on how to install packages, as opposed to [[Arch User Repository]]. This is to say that we could leave [[Template:Pkg]] as it is, change [[Template:AUR]] to {{AUR|package}}<sup><small>[[AUR]]</small></sup> and stop requiring the "available in *" wordings.<br />
::::Note that just updating [[Template:AUR]] would make heaps of articles look weird, as they'd get two links to [[AUR]] very close to each other; a safer alternative could be:<br />
::::# copy [[Template:AUR]] to [[Template:AUR_temp]]<br />
::::# change all the current instances of [[Template:AUR]] to [[Template:AUR_temp]] using a bot<br />
::::# update [[Template:AUR]] to the new style<br />
::::# change all the instances of [[Template:AUR_temp]] back to [[Template:AUR]] manually, removing the "available in [[AUR]]" parts<br />
::::([[Template:AUR]] and [[Template:Aur]] are backlinked by almost [[Special:MostLinkedTemplates|1500 pages]] though)<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:03, 27 July 2013 (UTC)<br />
<br />
:::::I'm a bit late to the party, but I think this is the best and safest idea! As a side note, instead of {{ic|<nowiki>{{AUR_temp|package}}</nowiki>}}, we could maybe use something like {{ic|<nowiki>{{AUR|package|noicon}}</nowiki>}}, that can exist permanently, for use cases where the <sup><small>[[AUR]]</small></sup> is unwanted. -- [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 16:17, 9 July 2014 (UTC)<br />
<br />
::::::Unfortunately that's impossible to implement without any [[mw:Lua scripting|scripting]]. You'd need at least primitive condition clause to adapt the output based on whether the argument is defined or not. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:03, 9 July 2014 (UTC) <br />
<br />
:::::::Oh I'm sorry, I thought that functionality was built-in in MediaWiki. But if not, we could do {{ic|<nowiki>{{AUR|package}}</nowiki>}} and {{ic|<nowiki>{{AUR_noicon|package}}</nowiki>}}. -- [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 18:46, 9 July 2014 (UTC)<br />
<br />
::::::::I haven't tested it, but I think it would be possible to make [[Template:AUR]] hide the superscript with {{ic|<nowiki>{{AUR|package|}}</nowiki>}} (note the final pipe) or {{ic|<nowiki>{{AUR|package|noicon=}}</nowiki>}}, however for Simplicity I can't really think of any cases where we'd need that functionality.<br />
::::::::Putting that aside, I'd be ready to implement the plan I outlined above, but not before completing [[Help talk:Style/Article summary templates#Deprecation of summaries and overviews]] and [[Template talk:Wikipedia#Deprecation]].<br />
::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:25, 10 July 2014 (UTC)<br />
<br />
:::Other possibility could be to create separate templates for use in lists of applications, where the need to differentiate AUR and Pkg is obvious. I think it is not needed in article introductions etc., there are already phrases like "available in the [[official repositories]]" or "available in the [[AUR]]".<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:31, 24 July 2013 (UTC)<br />
<br />
::::I like the other idea more, for simplicity, however this alternative can of course be taken into consideration. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:03, 27 July 2013 (UTC)<br />
<br />
:::::It's a good solution to make it {{AUR|package}}<sup><small>[[AUR]]</small></sup>, because it has a good appearance and eliminates the need to write ''available in the *''. I think there's no need to use a separate template for [[List of applications]] or another articles, because such info (that package is in AUR) will never be reduntant. With this method we can leave [[Template:Pkg]] unchanged -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 15:01, 9 July 2014 (UTC)<br />
<br />
::::::Yeah, the idea about the separate template is discarded, let's focus on the other branch of this discussion above. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:30, 10 July 2014 (UTC)<br />
<br />
=== Recommended wording ===<br />
<br />
With a new template, offered by Kynikos, we must use another sentences to say about installing of packages. There're some options:<br />
<br />
# [[Arch User Repository#Installing packages|Install]] {{AUR|package}}<sup><small>[[AUR]]</small></sup><br />
# Install {{AUR|package}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup><br />
<br />
The second one have a link to section, not to a whole article.<br />
So, the first one is good, because that's the way of wording, recommended for packages from official repositories, but it has two links to the same article. The second one solves that issue, but in this case it will differ from wording of official packages. Opinions?<br />
<br />
P.S. Or maybe it will be better not to use a link to a particular section? If so, we can use the following wording:<br />
<br />
* [[pacman#Installing specific packages|Install]] {{Pkg|package}} - for official repositories<br />
* Install {{AUR|package}}<sup><small>[[AUR]]</small></sup><br />
<br />
-- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 13:02, 10 July 2014 (UTC)<br />
<br />
:I think we can indeed link to specific sections:<br />
:* {{ic|<nowiki>[[Install]] {{Pkg|package}}</nowiki>}} [[Install]] {{Pkg|package}}<br />
:* {{ic|<nowiki>Install {{AUR|package}}</nowiki>}} Install {{AUR|package}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup><br />
:Note the use of the [[Install]] redirect to pacman, which, besides being simpler, will allow easily updating all the links in case the relevant section in [[pacman]] is renamed; we may use it also for AUR packages, I think it wouldn't be confusing:<br />
:* {{ic|<nowiki>[[Install]] {{AUR|package}}</nowiki>}} [[Install]] {{AUR|package}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup><br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:54, 12 July 2014 (UTC)<br />
<br />
::I'm all for better templates, but keep in mind that {{ic|<nowiki><sup></nowiki>}} adds slight distance between previous and current lines, which looks slightly uglier to me. Compare:<br />
----<br />
::asdf safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad {{AUR|glfw3-git}} (CURRENT TEMPLATE) f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f {{AUR|glfw3-git}} asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads<br />
----<br />
::asdf safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad {{AUR|glfw3-git}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup> (NEW TEMPLATE) f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads {{AUR|glfw3-git}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup> fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad {{AUR|glfw3-git}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup> sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads<br />
::[[User:Axper|axper]] ([[User talk:Axper|talk]]) 05:13, 12 July 2014 (UTC)<br />
<br />
:::True, thanks for mentioning it, however it's easily fixed with {{ic|<nowiki><sup style="line-height:0;"></nowiki>}}:<br />
:::<div style="border:1px dashed black;float:left;width:200px;margin-right:1em;">neio ien eoi ien eioie neoi ien eoi {{AUR|tsra}}<sup style="line-height:0;"><small>[[Arch User Repository#Installing packages|AUR]]</small></sup> ne ooien neoiien neoi ioen neoi oien ne ineo ien</div> <div style="border:1px dashed black;float:left;width:200px;">neio ien eoi ien eioie neoi ien eoi {{AUR|tsra}} ne ooien neoiien neoi ioen neoi oien ne ineo ien</div> <div style="clear:both;"></div><br />
:::If I remember well it works on all the major browsers.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:49, 12 July 2014 (UTC)<br />
<br />
::::Yeah looks good! (on Firefox) [[User:Axper|axper]] ([[User talk:Axper|talk]]) 06:02, 12 July 2014 (UTC)<br />
<br />
::About that: {{ic|<nowiki>[[Install]] {{AUR|package}}</nowiki>}} [[Install]] {{AUR|package}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup><br />
::Oh no, think about ArchLinux's newcomers: they'll see a link to command {{ic|pacman -S ...}} (and it tells, that it's a command for installation of packages) and another link to a not-small list of incomprehensible actions. After that any newcomer will try to install AUR packages via {{ic|pacman -S}}<br />
::-- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 10:28, 16 July 2014 (UTC)<br />
<br />
:::Well this can make sense, besides users can learn to install AUR packages with makepkg -i which would avoid using pacman directly altogether. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:25, 17 July 2014 (UTC)<br />
<br />
== Daemons and modules ==<br />
===<s> Wording </s>===<br />
<br />
We need a more generic standard phrasing when requesting to "add daemons to the DAEMONS array..." (even avoid making reference to rc.conf, since [[Daemons]] links there already?) in the vein of what's been done with installation instructions, and point more clearly to [[Daemons]]. Similar problem with kernel modules and the MODULES array. Also the instructions for starting/stopping daemons and for adding/removing modules could be merged in the sentence.<br />
<br />
I'd like to start a brainstorming session here to find the right wording example(s) to put in the guide. Of course objections to the whole idea are still taken into consideration.<br />
<br />
We probably need a standard phrasing for immediate starting/stopping/loading/removing only, another standard for adding to DAEMONS/MODULES only and a third one for the cases where both immediate and automated action are recommended. I'll start with (I repeat, this is a brainstorming session):<br />
<br />
*"[[Daemons#Performing daemon actions manually|Start]] the {{ic|foobar}} daemon."<br />
*"[[Kernel Modules#Loading|Load]] the {{ic|foobar}} module."<br />
*"Add the {{ic|foobar}} daemon to the [[Daemons#Starting on Boot|DAEMONS]] array."<br />
*"Add the {{ic|foobar}} module to the [[Rc.conf#Hardware|MODULES]] array."<br />
*"[[Daemons#Performing daemon actions manually|Start]] the {{ic|foobar}} daemon and add it to the [[Daemons#Starting on Boot|DAEMONS]] array."<br />
*"[[Kernel Modules#Loading|Load]] the {{ic|foobar}} module and add it to the [[Rc.conf#Hardware|MODULES]] array."<br />
<br />
Note that if we solve the problem of links color and font-weight as explained at the bottom of [[#Style vs. Usability]], the links will always be blue/purple and bold, even in indented paragraphs. For now you can fake this effect by enclosing links in {{ic|<nowiki>'''</nowiki>}}.<br />
<br />
-- [[User:Kynikos|Kynikos]] 16:17, 31 January 2012 (EST)<br />
:* I moved this part to the separate section as this discussion is not directly related to "formatting bloat" but rather to unification of phrasing.<br />
:* Exact formatting depends on results of [[#Bold and italic]] discussion, so I propose to finish it before continuing this one.<br />
:>> objections to the whole idea are still taken into consideration<br />
:Well, I have already understood reasons for deprecating installation instructions and modules loading at startup/daemons autostart. All this is performed only once and there are a lot of troubles with giving command line snippets for this. But what's wrong with starting/stopping daemons? I'd better suggest to allow usage of snippets for this purpose but only for other reasons than creation of whole "Starting xxx manually" section, containing only that single line of code. IMHO, it is usually enough to mention existence and purpose of daemon in given package and providing link to [[Daemon]]. All daemons behave similarly, interaction with them in Arch is really simple; there is simply no need for adding same sections with same contents for ''every'' article. If writing snippet is really required to maintain workflow of step-by-step guide, then there is probably no need for restricting it (the same for loading/unloading) modules.<br />
:--[[User:AlexanderR|AlexanderR]] 19:44, 31 January 2012 (EST)<br />
::Eheh with "whole idea" I meant the idea expressed in the first paragraph, since I was asking for possible methods of applying it without apparently leaving room for objections. I admit it wasn't clear at all :) So, just to give you an answer, it would look a bit inconsistent to me to allow daemon starting/stopping instructions and not installation instructions, also because we should resort to using snippets like:<br />
:::You must now start the '''whatever''' daemon:<br />
:::{{bc|# rc.d start whatever}}<br />
::Which looks redundant to me, unless you wanted to suggest something like:<br />
:::Now run:<br />
:::{{bc|# rc.d start whatever}}<br />
::Which I like even less because it's not teaching anything, it just leads the inexperienced user to copy-paste the command, without thinking of what he's doing.<br />
::If you had something different in mind, just give an example. -- [[User:Kynikos|Kynikos]] 18:20, 3 February 2012 (EST)<br />
:::Again from [[PulseAudio]]:<br />
:::{{Box||If the D-Bus system daemon is not already running, start it:{{bc|# rc.d start dbus}}<br>PulseAudio can be started with:{{bc|$ pulseaudio --start}}<br>Or if you use X11:{{bc|$ start-pulseaudio-x11}}}}<br />
:::Lets break workflow:<br />
:::{{Box||PulseAudio depends on '''dbus''' [[daemon]], so first run it.<br>PulseAudio can be started with:{{bc|$ pulseaudio --start}}<br>Or if you use X11:{{bc|$ start-pulseaudio-x11}}}}<br />
:::What looks better? --[[User:AlexanderR|AlexanderR]] 00:37, 4 February 2012 (EST)<br />
::::This argument seems rather circular. I fully support the last comment by Kynikos. And personally, I would combine the first two sentences in AlexanderR's second example to something like:<br />
:::::Since PulseAudio depends on the {{ic|dbus}} daemon, [[Daemon|start]] dbus and then start PulseAudio:<br />
::::~ [[User:Filam|Filam]] 22:43, 4 February 2012 (EST)<br />
:::::Like this?<br />
:::::{{Box||Since PulseAudio depends on the {{ic|dbus}} daemon, [[Daemon|start]] dbus and then start PulseAudio:{{bc|$ pulseaudio --start}}<br>Or if you use X11:{{bc|$ start-pulseaudio-x11}}}}<br />
:::::[[Wikipedia:Looks|Looks]] nice, except usage of verb in link to [[daemon]] article: I [[Wikipedia:agree|agree]] with [[User:Vadmium]] about the fact that usage of such [[Wikipedia:WP:easter_egg|easter_egg]] links [[Wikipedia:can|can]] a bit annoying and sometimes even misleading.<br />
:::::PS I am not going to challenge already reached agreement on deprecation of daemon instructions, so please consider adding something useful to [[#Quoting and underlining]] and [[#Bold and italic]] discussions, so that we can continue this one. --[[User:AlexanderR|AlexanderR]] 00:40, 5 February 2012 (EST)<br />
<br />
::::::Since we mentioned services in [[Help:Reading]], using "easter egg" links in these cases should be ok, just like we're doing with installation instructions (we're not writing "install {{Pkg|somepackage}} with [[pacman]]"). I'm closing this discussion, the rest should be handled by the discussions below. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:01, 30 August 2014 (UTC)<br />
<br />
===<s> Daemon operations </s>===<br />
I'd like to suggest you / we add wording & style suggestions for systemd daemon operations to [[Help:Style#Daemon_operations]]. --[[User:Stefanwilkens]]<br />
<br />
:Agreed, can you start with an example of suggestions? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:58, 3 October 2012 (UTC)<br />
::Considering that giving direct examples that can be copy pasted is deprecated, I would suggest something like this:<br />
::Use [[Systemd#Using_Units|systemctl]] to enable <servicename> with <servicefile> during boot.<br />
::{{Note|Use [[Systemd#Using_Units|systemctl]] to enable GDM with {{ic|gdm.service}} during boot.}}<br />
::Or the more to the point:<br />
::<Action> <servicename> with <servicefile> using [[Systemd#Using_Units|systemctl]].<br />
::{{Note|Start GDM with {{ic|gdm.service}} using [[Systemd#Using_Units|systemctl]].}}<br />
::{{Note|Enable GDM at boot time with {{ic|gdm.service}} using [[Systemd#Using_Units|systemctl]].}}<br />
::Upon review of this, it seems that we may only have to adjust the references to rc.d and the old DAEMONS array from [[Help:Style#Daemon_operations]] and replace it with instructions fitting to systemd. For example:<br />
:::'''Daemon operations'''<br />
:::* The standard phrasing is a simple list of the daemons involved, possibly remarking dependencies or conflicts with other daemons, and a link to [[Daemon|Daemon]].<br />
:::* If a required action is not covered in [[Daemon|Daemon.]], it is acceptable to provide an example. Such an example should make use of the {{ic|systemctl}} command and provide a listing of the service files involved.<br />
:::* The Beginners' Guide and its subpages are the only exceptions to the rules above.<br />
::Just suggestions to get the ball rolling, nothing is worse that outdated documentation. --[[User:Stefanwilkens|stefanwilkens]] ([[User talk:Stefanwilkens|talk]]) 18:25, 14 October 2012 (UTC)<br />
<br />
:::Wrt [[#Passing arguments to systemd units: give example commands or not?]], here are a few suggestions to control [[systemd#Using units|instantiated units]]:<br />
:::{{Box||The {{ic|rfkill-block@.service}} [[systemd#Using units|template unit]] can be used to block given device type at boot, for example {{ic|rfkill-block@bluetooth.service}}.}}<br />
:::{{Box||To enable automatic switching of ''netctl'' profiles on a wireless interface, enable the {{ic|netctl-auto@.service}} [[systemd#Using units|template unit]]'s instance, for example {{ic|netctl-auto@wlan0.service}}.}}<br />
:::If the term "template unit" will catch on, we could create a redirect for it to simplify the linking.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:15, 23 August 2014 (UTC)<br />
<br />
::::I don't know, I've implemented my idea directly in [[Help:Style#Systemd units operations]] so we have something more tangible to work on (yes, I've also updated the heading, as the word "daemon" seems to have fallen a bit into disuse, replaced by "service", "unit" etc.).<br />
::::Regarding your proposal, I'd like to keep using the same kind of word as the anchor text for the link to [[systemd]], for consistency (i.e. the ''systemctl'' action). Then I'd avoid to use both "template" and "instance" in the same sentence, which sounds a bit redundant: it should be enough to say, more concisely, something like "an instance of {{ic|unit@.suffix}}".<br />
::::What do you think?<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:47, 26 August 2014 (UTC)<br />
<br />
:::::Your version is simpler indeed, I have no objections. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:08, 26 August 2014 (UTC)<br />
<br />
::::::Thanks, I'm closing this discussion then: perhaps the rules/examples may be improved further, but let's use new discussions for that when somebody comes up with a good idea. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:06, 30 August 2014 (UTC)<br />
<br />
=== Passing arguments to systemd units: give example commands or not? ===<br />
<br />
About [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=319448&oldid=319444], [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=next&oldid=319448] and [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=next&oldid=319449]: the current version makes it look like there is a file {{ic|dhcpcd@''interface_name''.service}} somewhere in the file system, the following sentence tries to explain that it is just an argument. IMO the original version was all clearer, more accurate and shorter, so I wonder if we can tolerate ''giving examples of how to manipulate systemd units taking arguments'', excepting it from the current rule. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:29, 26 June 2014 (UTC)<br />
<br />
:Are [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=321632&oldid=321570] and [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=321634&oldid=321632] clearer? Perhaps it would be easier to add a paragraph to [[systemd#Using_units]] explaining arguments, rather than add an exception. After all, many {{ic|.service}} files take arguments; on my install:<br />
<br />
:{{bc|<nowiki><br />
$ locate "@.service" | wc -l<br />
48<br />
</nowiki>}}<br />
<br />
:--[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:32, 26 June 2014 (UTC)<br />
<br />
::Oh well, the rule on daemons has certainly been one of the most controversial through time, it was originally designed for rc.d scripts [https://wiki.archlinux.org/index.php?title=Help:Style&oldid=163286#Daemon_operations] and after the switch to systemd it was only "translated", without doing any other adaptations.<br />
::systemd is certainly more powerful and we should start keeping that into account: I like Alad's idea, we should introduce unit '''instances''' (not "arguments") in [[systemd]], also for educational purposes, without excepting the style rule. I would seriously consider adding brief systemd guidelines to [[Help:Reading]] (or maybe just a link to [[systemd]]). Finally we should add well-designed wording examples to [[Help:Style#Daemon operations]] (see discussions above), like we've done for installation instructions: in case of unit instances we should use the word "instance" (or whatever word we decide to use) to link to the newly created section in [[systemd]].<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:18, 28 June 2014 (UTC)<br />
<br />
:::I was quite surprised to find out that the description of ''instantiated units'' is missing in [[systemd]] (I guess Archers are fine with man page). I agree that there should be at least a short intro, something we can link to. [https://coreos.com/docs/launching-containers/launching/getting-started-with-systemd/#instantiated-units This] looks nice, we could put together something similar. And use more external links of course, unfortunately I can't access [http://0pointer.de/blog/projects/systemd.html Lennart Poettering's blog], which as far as I remember described it quite well. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:59, 29 June 2014 (UTC)<br />
<br />
::::Lennart's site seems to go down intermittently, right now it works again... --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:10, 29 June 2014 (UTC)<br />
<br />
:::::Marked [[Systemd#Using units]] for expansion. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:58, 30 June 2014 (UTC)<br />
<br />
::::::I would leave it with a bullet for mentioning "instantiated" in that section and had a go on it (please check): [https://wiki.archlinux.org/index.php?title=Systemd&diff=331763&oldid=331698]. <br />
::::::Perhaps one of the instantiated ones most troublesome for users could be used as an item in [[Systemd#Troubleshooting]] to give a practical example? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:27, 21 August 2014 (UTC)<br />
<br />
:::::::I've improved the bullet point a bit and removed the Expansion flag.<br />
:::::::About [[Systemd#Troubleshooting]], would you use a unit instance in place of {{ic|systemd-modules-load}}? Maybe that can be discussed in [[Talk:Systemd]], honestly I'd be neutral about it.<br />
:::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:53, 23 August 2014 (UTC)<br />
<br />
::::::::I think that the current note is OK, thank you both for implementing it. From the first Kynikos' reply, we have yet to add recommended wording(s) to [[Help:Style#Daemon operations]]. I will add some suggestions for enabling instantiated units into [[#Daemon operations]].<br />
::::::::Wrt adding brief systemd guidelines into [[Help:Reading]], the same could be done for installing packages (and loading kernel modules and similar). Given that there will always be an explicit link to "[[pacman|install]]" or "[[systemd#Using units|enable]]" or "[[Kernel modules|load]]", things are pretty simple for the reader: they either know and do as being told, or just follow the link. [[Help:Reading#Append.2C_create.2C_edit_and_source|Editing config files]] is different in that there is not any accompanying link, hence the entry in [[Help:Reading]]. We could describe the Hypertext metaphor there, but I think that unlike editors, readers tend to follow it naturally.<br />
::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:27, 23 August 2014 (UTC)<br />
<br />
:::::::::Well, I was still thinking that some words in [[Help:Reading]] could fit the purpose of that article, also because it's linked from [[Main page#Help]] and it looked a bit incomplete without those basic examples, so I've gone ahead and added them, feedback is welcome. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:04, 25 August 2014 (UTC)<br />
<br />
::::::::::Reads perfect. Two small suggestions: under "$makepkg -si" I would add "to create and install the package with required dependencies.". Then, due to frequent usage, I would add ", ''enable''" to the first sentence [[Help:Reading#Control_of_systemd_units|here]]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:45, 26 August 2014 (UTC)<br />
<br />
:::::::::::Right, I've added "enable", but about makepkg I won't take action because [[Help:Reading]] is not really meant to give explanations, for that there are the main articles like [[AUR]] and [[makepkg]].<br />
:::::::::::Branch closed. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:20, 30 August 2014 (UTC)<br />
<br />
:Re Lahwaacz's original item I agree that using real examples instead of fictionary variables should avoid confusion, and now we have background explanation of "instances". I have edited the exemplified article with: [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=332005&oldid=322226], [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=332006&oldid=332005]. Works? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:39, 23 August 2014 (UTC)<br />
<br />
::Looks good to me, thanks for updating it. Regarding interface names, I'd suggest using the "old-school" names ({{ic|eth0}}, {{ic|wlan0}} etc.) as a transition between the predictable names ({{ic|enp0s25}} and similar/worse atrocities) and pseudo-variables ({{ic|''interface''}}, {{ic|''client_side_interface''}} etc.) because out of these three, the "old-school" names are probably the easiest to understand. If an appropriate note linking to [[Network configuration#Device names]] and stating the conventions '''for the given article''' is provided, even the users used to the predictable names should understand just fine. Also, [[Internet sharing]] uses a profound convention and introduces fictional interfaces {{ic|net0}} and {{ic|internet0}} to avoid long pseudo-variables like {{ic|''wan_interface''}} and {{ic|''client_side_interface''}}, so I don't mind fictional interface names either. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:19, 23 August 2014 (UTC)<br />
<br />
:::Well, one reason articles like [[Internet sharing]] introduced fictional names was also that they required interface persistence before predictable names were introduced. It's always context that makes one or the other seem more useful and, like you say, stating conventions. For example, I believe it's very important article's like the BG guide use predictable names, and explain them like they do. However, using those everywhere gets really awkwardly inconsistent over time, because if content gets gradually edited it's obvious that a command line output from editor2 will show another interface than the output in the paragraph above. That's another reason why I'm fully +1 with your suggestions. Let's see we keep it consistent in article context, conventions stated/crosslinked as applicable and prefer easy to grasp/recognisable short forms. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:46, 24 August 2014 (UTC)<br />
<br />
::::So, I'm a bit neutral here, do we want to explicitly invite to be consistent throughout each article without recommending any kind of name types? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:20, 30 August 2014 (UTC)<br />
<br />
=== Remove the rules on modules? ===<br />
<br />
The need for [[Help:Style#Kernel modules operations]] descends from the initscripts times, when the modules to be loaded had to be listed in rc.conf and it was too repetitive to always say how to edit that file. However, systemd and udev have made the need to explicitly load modules much more infrequent, so I'm wondering if we really still need those style rules, or if instead we can remove them and allow writing simple module loading instructions where specifically required. A link to [[kernel modules]] would still be encouraged by [[Help:Style#Hypertext metaphor]].<br />
<br />
In case it wasn't clear enough, I'm for removing the section.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:58, 26 August 2014 (UTC)<br />
<br />
== Better structuring ==<br />
<br />
IMHO, many parts of article can be safely moved to descriptions of corresponding templates. For example, information about [[Template:Keypress]] actually belongs to template itself rather than this style guidelines. I believe, most people look at template page before using it. What do you think? --[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
:Actually this idea would overlap with a larger project I've had in mind for some time now: merging editing and style guidelines consistently everywhere, and split them in several articles based on the various topics being dealt with. However I'd like to plan this carefully in advance, as it involves several pages, otherwise we risk increasing the mess instead of reducing it. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:04, 14 May 2012 (UTC)<br />
::> ..merging editing and style guidelines consistently everywhere, and split them in several articles based on the various topics being dealt with.<br />
::Sounds good. Note, that moving part of current content to templates can reduce overall size of all involved articles and possibly simplify further work. --[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
:See also [[#Help:Talk]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:11, 25 December 2012 (UTC)<br />
<br />
I was wondering, why the style guidelines are kept in the ''Help:'' namespace? I think that ''ArchWiki:'' would suit the rules better, then ''Help:'' could be reserved for examples, recommendations and guides (not guidelines). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:30, 23 August 2014 (UTC)<br />
<br />
:But with that reasoning nothing would be left in [[:Category:Help]] ^^ I know you're making the comparison with [[Wikipedia:Wikipedia:MoS]], I'm not aware of Wikipedia's policy about the scope of the two namespaces (but I've seen many Wikipedia:... articles under the Help category there, either directly or under a descendant, while Category:Wikipedia seems to contain articles that talk about Wikipedia in an encyclopedic way, and they're not in the Wikipedia's namespace).<br />
:In our wiki, I think we tend to have a correspondence (or redundancy) between the Help and ArchWiki namespaces and categories: Help is more for articles that are meant to show editors the proper way to contribute (and so yes, for coherence I'd move [[ArchWiki:Contributing]] there instead), and ArchWiki is more for articles that are about the wiki itself (not Arch Linux), including the pages that are used by the staff to ease maintenance. Also note that [[:Category:Help]] is a child of [[:Category:ArchWiki]].<br />
:In short, I'd leave Style where it is, and maybe I'd improve the correspondence between namespaces and categories, thus moving [[Table of contents]] under ArchWiki:, together with [[ArchWiki Translation Team]], and then there are also some uncategorized titles in [[Special:PrefixIndex/ArchWiki:]], we could consider categorizing them.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:20, 25 August 2014 (UTC)<br />
<br />
== Related links ==<br />
<br />
=== See also or Related in Article Summary? ===<br />
<br />
I think we'd better be coherent whether to keep links, references etc. either in a "See also" section at the bottom of the article, or in one (or more) boxes under the Article Summary at the top right of the article.<br />
<br />
See also [[#Article summary templates]].<br />
<br />
-- [[User:Kynikos|Kynikos]] 15:15, 21 September 2011 (EDT)<br />
<br />
:This is more a reminder than other, but I'm starting to like the idea of adding the rule to keep related ArchWiki articles in the Article Summary box only, and external links in See also sections only. Well, this way the "See also" default may even be changed (with bots, don't worry!) to a non-imperative, descriptive title like "Additional resources", "External links" or something like that. -- [[User:Kynikos|Kynikos]] 07:06, 14 December 2011 (EST)<br />
:Also remember that many external links in summaries can be found with [[Special:WhatLinksHere/Template:Article_summary_link]]. -- [[User:Kynikos|Kynikos]] 07:41, 24 January 2012 (EST)<br />
<br />
'''Advantages of links in See also:'''<br />
*There is more space for link descriptions<br />
*It is likely one will read or skim the article before actively looking for additional reading material. This naturally leaves the reader at the end of the article. It is convenient for the reader in this case if links are at the end of the article. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*It ''seems'' more common (elsewhere) to have links at the end of articles (when they are not inline with the rest of the text). Following common convention it may be better from a usability perspective. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*:Especially for people used to Wikipedia, which uses the same wiki software. [[User:Vadmium|Vadmium]] 11:12, 26 October 2011 (EDT).<br />
*I am not sure how much we care about this but it having the links at the end could be more friendly to small form factor screens and screen readers. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*As a section, "See also" gets its own TOC entry granting easy access from near the top of the article. Alternatively one may press the END key. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*More formatting options here than in summary. [[User:Emiralle|Emiralle]] 13:12, 15 October 2011 (EDT)<br />
*More inclined to put external, or less closely related stuff here. [[User:Emiralle|Emiralle]] 13:12, 15 October 2011 (EDT)<br />
*''See also'' section would not be skipped if you start reading the main text sequentially from the top. [[User:Vadmium|Vadmium]].<br />
*''[add more advantages...]''<br />
<br />
'''Advantages of links in Article Summary:'''<br />
*Immediately visible<br />
*Beyond some minor editing inconvenience, is there any real disadvantage of having the most ''interesting'' links in both locations? It could be advantageous for the reader to have some links in both locations. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*I think putting very closely related links in the summary gives the topic more cohesion, and as James Eder said, they could be included at the bottom as well. [[User:Emiralle|Emiralle]] 13:12, 15 October 2011 (EDT)<br />
*It would theoretically be more effective in preventing duplication of content within the wiki, as (unexperienced) editors would have a clearer view of the articles where related content could already exist (true especially with series (or "rings") of articles on the same subject). -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:46, 29 September 2013 (UTC)<br />
*''[add more advantages...]''<br />
<br />
=== Lists ===<br />
Inspired by [https://wiki.archlinux.org/index.php?title=Sound_system&curid=10626&diff=201543&oldid=197917], I was wondering if related links in "See also" sections or article summaries should be avoided if already present in the body of the article. I'd prefer having complete lists of related articles even if that implies duplicating some of them. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:09, 16 May 2012 (UTC)<br />
:> I'd prefer having complete lists of related articles even if that implies duplicating some of them<br />
:I'd prefer this way as well. Sadly listing ''all'' related articles may occupy most of vertical space, so there should be clear guidelines regarding choise of related links. And editors often don't have time to read even [[Help:Style]]... On the other hand, defining simple rule like "only links not present in text" can eliminate the very requirement for any additional rules. --[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
:: "only links not present in text" is too strict I think. Related links make some page more "visible" to readers. For example, I often click on them to learn more info about the same topic. But to be honest, I rarely click on the "in page links" even the links shown clearly in "See Also". They are much harder to be found and clicked. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 04:50, 19 May 2012 (UTC)<br />
<br />
=== Definition ===<br />
Inspired by [https://wiki.archlinux.org/index.php?title=Boot_Debugging&diff=prev&oldid=201554], I was wondering if we needed a definition of what are the conditions under which an article can be considered related to another one. Honestly I can't think of something suitable at the moment, if somebody has good ideas, they're welcome here. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:09, 16 May 2012 (UTC)<br />
:Few ideas:<br />
:* Alternatives to software, described in article<br />
:* Methods and techniques alternative to ones described in article<br />
:* Software <-> it's use case<br />
:* software/technique <-> it's developer<br />
:--[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
<br />
== Application name capitalization ==<br />
<br />
Which are the rules of capitalization of certain names? For LibreOffice there is no doubt, but for example is it 'bash' or 'Bash'? Probably the documented one is the preferable, so 'bash', 'Bash' when starts a sentence, aria2c everywhere. For zsh neither man pages are coherent. -- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 18:00, 19 May 2013 (UTC)<br />
<br />
:This topic is rather interesting: it's quite natural that we should follow the capitalization used in the upstream documentation, and this guide should probably mention it. I'd also like to remark whether the name should be always capitalized at the beginning of a sentence or not: honestly my position would be to still follow what the upstream documentation does.<br />
:In case the documentation is not coherent, I guess there's nothing we can suggest, except for being consistent throughout the article, _and_, if the application is mentioned in other articles, capitalization should be consistently based on the main article for that application (e.g. [[Bash]]).<br />
:Note that Bash is always capitalized in http://www.gnu.org/software/bash/<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:00, 22 May 2013 (UTC)<br />
::so Bash is written wrong in [[Help:Style#Shells]], (lol, forgive me :) ) -- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 10:29, 3 June 2013 (UTC)<br />
:::Ahah perfection is unreachable, you will always find something to report... Anyway in this case "bash" _would_be_ written "wrong" in [[Help:Style#Shells]] only if the above had already been enforced as a rule ;) (but I'll forgive you for this blunder, don't worry :P ) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:32, 3 June 2013 (UTC)<br />
<br />
::::I like the way the Git project uses both "Git" and "git" in their documentation based on what the author is referring to. They use "Git" when talking about the project/software generally, and they use "git" when referring to the ''compiled program used when running commands'' [https://github.com/git/git/blob/master/Documentation/CodingGuidelines#L313]. This style makes it quite easy to know whether to use "Bash" or "bash", etc.<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:42, 11 January 2014 (UTC)<br />
<br />
:::::That is certainly logical, with [[Help:Style/Formatting_and_Punctuation]] applied it would be "Git" (plain text, first letter uppercase) and "''git''" (italic, all lowercase). I believe that with proper context it would not be confusing, but for the controversial cases it's probably best to place a note with some explanation into the talk page, as it has been done for [[Btrfs]]: [https://wiki.archlinux.org/index.php?title=Talk:Btrfs&diff=291780&oldid=291779]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:09, 31 January 2014 (UTC)<br />
<br />
::::::In my view Git makes its spelling convention look more complicated than it is: IMHO it just says "always use 'Git', except when talking about the executable, which is a lower-case filename and couldn't be run otherwise". Anyway we could indeed enforce such a convention, but only for applications that A) don't have an official or common capitalization convention and B) are commonly run through an executable that has the same name as the application itself. This would of course settle Bash and Btrfs cases though. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:50, 1 February 2014 (UTC)<br />
<br />
==List of Applications and See also==<br />
# I suggest for lists like [[List_of_Applications/Multimedia]] to use capital letter for the first letter of the description, NO dots at the end (this behaviour seems to be preminent in Wikipedia) and to avoid totally articles ('A ..' is annoying). Is it ok?<br />
# In the same list it may be fair to put <nowiki>{{Grp|group}}</nowiki> beside items that have their one.<br />
# The '''See also''' section should be treated as above lists.<br />
<br />
-- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 18:00, 19 May 2013 (UTC)<br />
<br />
:I support 1. and 2. except for the dots at the end of descriptions, which I would require instead, since sometimes the App template has long descriptions, even made of several sentences, and including all the puntuation only omitting the final dot would look weird to me.<br />
:About 3. I don't understand what you mean, can you be more specific?<br />
:However I'm also wondering if these rules should be hosted here (if they refer to the use of Template:App) or in [[Talk:List of Applications]] (if they refer only to [[List of Applications]] and subpages).<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:23, 26 May 2013 (UTC)<br />
::About 3: I just mean that a section like [[Aria2#See_also]] must have capitalized letters and no dots (or whatever the standard would be).<br />
::About the hosting place: page like [[CD_Burning#Burning_CDs_with_a_GUI]] or [[Conky#AUR_packages]] are not directly related to [[List of Applications]], so I think it is worth to host a rule here. Plus this rule would apply also to any other list, like [[E4rat#Process]] --[[User:Flu|Flu]] ([[User talk:Flu|talk]]) 16:53, 26 May 2013 (UTC)<br />
:::Still about 3: I see, usually See-also links have much shorter descriptions, in that case I would apply a no-dot policy. Still open to more opinions though.<br />
:::Hosting place: a rule about lists of applications would probably best fit in [[Template:App]], also in light of my plans to decentralize style rules in general. A rule about See also sections would instead fit this guide indeed, at least for the moment.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:17, 28 May 2013 (UTC)<br />
<br />
== One link to the package in a paragraph is enough ==<br />
Do we need multiple links to the same package, wiki article etc. in the same paragraph? I understand that if the article is very long, the links may be used in different sections, but isn't "[[Arch_Boot_Process#Init_process|In the past, Arch used SysVinit as the init process. Now on new installs, Systemd is used by default. Existing SysVinit users are recommended to switch to systemd.]]" with 2 links to SysVinit and 2 links to systemd a bit too much? -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 23:15, 21 May 2013 (UTC)<br />
:First thing, probably in the title you mean links to articles in general, not only packages, right?<br />
:However, I definitely agree, I guess we could extend the rule to the same section or even the whole article, but I'd like to exclude some cases, like "See also" sections (see [[#Lists of related links]]), and to make the rule compatible with [[Help:Style#Official packages]] and similar.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:11, 22 May 2013 (UTC)<br />
::Just a reminder: this is affected by [[Help:Style/Formatting_and_Punctuation#First_instances]], not sure if it sould be mentioned directly on [[Help:Style]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:35, 1 September 2013 (UTC)<br />
<br />
== Red links ==<br />
Is creating links to nonexistent wiki articles a good thing because it encourages creation of [[Special:WantedPages|wanted pages]]? Is [https://wiki.archlinux.org/index.php?title=Getty&oldid=258135#Others this] OK or a bit too red? [https://wiki.archlinux.org/index.php/Template_talk:App One discussion] asserted that it's OK to create red links when using the app template, but I don't like them and I'd prefer not to litter articles with references to non-existent articles. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 13:12, 24 May 2013 (UTC)<br />
: I remember reading something like "Only add links to nonexisting wiki articles when you intend to add it soon". Forget where did I read it, but I agree with it. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 04:59, 25 May 2013 (UTC)<br />
::Fengchao's unknown quote doesn't sound bad to me either. This wasn't the central topic in [[Template talk:App#Introducing default argument]] by the way (that discussion is still valid, though). -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:39, 2 June 2013 (UTC)<br />
:::I removed the red links that were in English articles. Closing. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 22:03, 12 July 2013 (UTC)<br />
::::Reopening, I will add "Only add links to nonexisting wiki articles when you intend to add it soon" somewhere. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:16, 13 July 2013 (UTC)<br />
<br />
== Prefer linking to the article than to the package ==<br />
''When mentioning an application, prefer linking to its article, if existing, rather than directly to the package.'' -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:24, 28 May 2013 (UTC)<br />
:+1, apart from the standard "Download {{ic|foo}} from the official repos" and similar. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 13:27, 28 May 2013 (UTC)<br />
<br />
== git/vcs/source builds ==<br />
<br />
In some article there are source build instruction like [[Jumanji#Method_2:_From_Source]] and [https://wiki.archlinux.org/index.php?title=Logitech_Unifying_Receive&direction=prev&oldid=260677#From_AUR] or AUR git references like [https://wiki.archlinux.org/index.php?title=Bumblebee&oldid=259841#Installation]. I think they are pointless because:<br />
* of course you can build application on your own, there is no need to say that.<br />
* there is plenty of git/patched/vcs variants in AUR. One can decide to install them by their choice.<br />
What about a rule to forbid git/source references unless they are the only chance?<br />
::(oh no, another time) -- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 21:15, 2 June 2013 (UTC)<br />
:IMHO 'make && make install' instructions should go.<br />
:I have nothing against describing different AUR packages, whether VCS or not. PKGBUILDs are sometimes pretty complex and it's not obvious what's the difference between the various AUR versions of a package - if any.<br />
:Please sign your talk page edits [[Help:Discussion#Join_a_discussion]]. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 20:21, 2 June 2013 (UTC)<br />
::Yes, manual compilation instructions can be removed, but ''only'' when an AUR package is available. A rule may be added for this.<br />
::No, please don't remove links to "alternative" versions of packages in [[AUR]]; treat every AUR package as the others, there are not AUR packages more "official" than others: if they all install the same application, they _can_ (i.e. ''not'' _must_) be mentioned in the same article.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:05, 3 June 2013 (UTC)<br />
::Just mentioning a recent related example, [https://wiki.archlinux.org/index.php?title=Isync&diff=262333&oldid=253631], that I consider perfectly reasonable. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:10, 12 June 2013 (UTC)<br />
<br />
==<s> Ellipses in code examples </s>==<br />
<br />
Reminder: mention ellipsis as an allowed form of extraneous code in examples; [[Help:Style#Command line text]] is already forbidding comments next to commands and we're going to add formatting style rules for "pseudo-variables". -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:21, 13 July 2013 (UTC)<br />
<br />
:Implemented in [[Help:Style#Code formatting]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:03, 27 August 2014 (UTC)<br />
<br />
== Talk pages of redirects ==<br />
''[moved from [[User talk:Kynikos#Talk pages of redirects]] -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:01, 22 August 2013 (UTC)]''<br />
<br />
I didn't find any rule/official policy regarding talk pages of redirects, but you made me think about it.<sup>[https://wiki.archlinux.org/index.php?title=Special%3ALog&type=delete&page=Talk%3AXMPP]</sup> Should they be deleted (of course with the exception of actual issue regarding the redirect)? What would that mean for users (non-admins) - should the talk page be marked for deletion? Or explicitly ask some admin to delete it? Or should the talk page be just blanked (assuming all issues were solved before the redirect)? I ask because now I realized that I left quite a mess behind me when I redirected some pages. Anyway, I think that some specific instructions to either [[Help:Style#Redirect pages]] or [[Help:Editing#Redirects]] won't hurt. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:41, 21 August 2013 (UTC)<br />
<br />
:It's true, there's no written policy on this matter. Blanking a page is not an option in any case. If the redirect target's talk page doesn't exist, the redirect's talk page should be ''moved'' there (thus preserving its history); if the redirect target's talk page already exists, any redirect's talk page discussions should be ''merged'' there. The redirect's talk page can then be either redirected to the target's talk page (automatic when moving), fixing any double redirects, or marked for deletion ([[Help:Style#Redirect pages|without redirecting]]), fixing any backlinks first. Do we want to enforce only one of these possibilities or leave the choice case by case?<br />
:Note that admins and maintainers have the ability to move a page without leaving a redirect (deleting the original title), which could be taken into consideration, of course still taking care of fixing any backlinks first.<br />
:Finally, this could be part of an old [[User:Kynikos/Tasks#Ideas|idea]] of mine to create a page with checklists/procedures for the most common operations on articles, but that would be another discussion :)<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:19, 22 August 2013 (UTC)<br />
<br />
::Sorry for the delay, I've been inactive for a while.<br />
::Clearly discussions that become irrelevant after the redirect (like [[Talk:Tint#Merge with Tint2]]) can be removed. There may be discussions that are still relevant after the redirect (e.g. content related issues, can't find any good example right now), these issues should preferably be solved before redirecting the page, but that's up to the editor. I agree that remaining discussions should be moved/merged to the talk page of redirect target, so the question is what to do with the blank talk page?<br />
::I understand that there may be external websites with links to talk pages on ArchWiki and deleting the old talk page instead of redirecting it is rather unfriendly. On the other hand, those links are not used very often, especially for talk pages of some outdated, unmaintained or not very important pages. Just deleting it is much simpler (eh, the redirect is simple consequence of ''moving'' the whole talk page, but when the target talk page exists, deleting the source is simpler).<br />
::I also think that the redirects (at least for talk pages) should be deleted after some time, just another cleanup step. Especially if the main page was redirected for the second time (e.g. to fix some double redirect), take [[Talk:Suspend to Disk]] as an example.<br />
::Generally I don't have anything against redirects, it just makes the maintenance more difficult. For talk pages I think they are mostly superfluous.<br />
::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:11, 26 August 2013 (UTC)<br />
<br />
:::One problem I see is that deleting a redirecting talk page will make the history of any merged discussions inaccessible to normal users. Anyway this could be trivial, and recommending to mark the talk page for deletion would leave the final choice to an admin, who is supposed to be able to judge what's best to do, also considering redirecting as a possibility. So I've added a procedure to [https://wiki.archlinux.org/index.php?title=Help%3AEditing&diff=272909&oldid=272907 Help:Editing], do you like it? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:04, 28 August 2013 (UTC)<br />
<br />
::::Looks good. An idea: [[Help:Editing#Redirects]] could be split into three subsections, 1) what is a redirect, 2) when to redirect a page, 3) how to redirect a page. This could be applicable also to other procedures from your [[User:Kynikos/Tasks#Ideas|ideas]] and probably deserves separate discussion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:52, 28 August 2013 (UTC)<br />
<br />
::::As I said earlier, I messed up a few talk pages when redirecting. I've now marked most of them for deletion, see [[User:Lahwaacz#Messed_up_by_redirecting_the_main_page]] for quick list. The last one in the list, [[Talk:Map Custom Device Entries with udev]], contains two open discussions - I doubt they are still relevant, but I'll have to investigate further. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:47, 28 August 2013 (UTC)<br />
<br />
== Distinguish fragment identifier interwiki links? ==<br />
<br />
Similarly to [[#Visited_links_color]], can we distinguish [[Wikipedia:Fragment identifier|fragment identifier]] interwiki links (those written as {{ic|<nowiki>[[#foo]]</nowiki>}}) from other interwiki links (generally pointing to some other page)? I find something like {{ic|<nowiki>[[#PolicyKit authorization|PolicyKit authorization]]</nowiki>}} [https://wiki.archlinux.org/index.php?title=Libvirt&diff=next&oldid=274533] kind of confusing, it should be clear that the link points to a section on current page and not to separate page. Possibilities:<br />
<br />
# prefer {{ic|<nowiki>[[#foo]]</nowiki>}} instead of {{ic|<nowiki>[[#foo|foo]]</nowiki>}} - this does not solve something like {{ic|<nowiki>[[#Run daemon|run the daemon]]</nowiki>}}, also note that the fragment is case-sensitive<br />
# add some icon (superscript?) in front of/behind the link, I was thinking about the arrow shown in [https://wiki.archlinux.org/index.php?title=Help_talk:Style&action=history history pages] (but without the link to the section)<br />
# use some other color<br />
<br />
I'd vote for the second, it seems to be the most universal. Or does anybody have some other suggestion?<br />
<br />
(Looking at the second link in this post, something similar could be done for links to Wikipedia. In this case, I propose adding superscript {{ic|W}} behind the link.)<br />
<br />
Sorry if this has already been discussed somewhere else, I don't have the time to search it right now.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 7 October 2013 (UTC)<br />
<br />
:Talking of distinguishing links, external https links are not distinguished either:<br />
::[http://foobar.org http]<br />
::[https://foobar.org https]<br />
:Perhaps a bug?<br />
: -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:10, 10 October 2013 (UTC)<br />
<br />
::About the little icons next to links, I guess we could do it easily with CSS attribute selectors in the skin files.<br />
::About the https icon in particular, it looks it was disabled on purpose for some reason: [https://projects.archlinux.org/vhosts/wiki.archlinux.org.git/tree/skins/archlinux/arch.css] (line 67) I'd be curious to know why.<br />
::Of course to implement all this, a bug report should be opened and very likely patches should be prepared, so if you think you have the time to work on it, the project is at [https://projects.archlinux.org/vhosts/wiki.archlinux.org.git/] with links to clone the repo. I'd be interested in giving a hand of course :)<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:53, 10 October 2013 (UTC)<br />
<br />
:::Thanks for pointing me to the right direction, here's the commit about the https links: [https://projects.archlinux.org/vhosts/wiki.archlinux.org.git/commit/skins/archlinux/archlinux.css?id=e8b7a08c663a0fb392a24c67ec1dea59057f480a].<br />
:::Let's see if I can get to this again this weekend...<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:05, 10 October 2013 (UTC)<br />
<br />
::::I sent an email to [[User:Pierre|Pierre]] about the commit in November and did not receive any reply, so I submitted a bug report: {{Bug|38769}} - hopefully it won't be missed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:00, 2 February 2014 (UTC)<br />
<br />
:::::We'll see, I've submitted a patch, but unfortunately wiki bugs, even if easy to fix, have a [https://bugs.archlinux.org/task/35545 long life]... -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:17, 3 February 2014 (UTC)<br />
<br />
== Problem with keyboard keys style ==<br />
<br />
I could use some help with [[Keyboard Shortcuts]]:<br />
<br />
<s>According to [[Help:Style#Keyboard_keys]], {{ic|Ctrl}}+{{ic|Alt}}+{{ic|+}} should be {{ic|Ctrl+Alt++}}, but is that clear enough? (see [[Keyboard_Shortcuts#X11]])</s><br />
<br />
Also, what would be the preferred style for showing multiple shortcuts for some modifier combination?:<br />
<br />
* {{ic|Alt}}+{{ic|.}}or{{ic|_}}<br />
* {{ic|Ctrl}}+{{ic|Alt}}+{{ic|+}}/{{ic|-}}<br />
* {{ic|Ctrl}}+{{ic|Alt}}+{{ic|F1}}, {{ic|F2}}, {{ic|F3}}, ...<br />
<br />
(note: someone used {{ic|&uArr; Shift}} on that page, the arrow looks really funny :D )<br />
<br />
'''Edit:''' the {{ic|Ctrl+Alt++}} shortcut was either dropped from X or is specific to NVIDIA, so I've [https://wiki.archlinux.org/index.php?title=Keyboard_Shortcuts&diff=288958&oldid=288082 removed it] from the list of standard shortcuts. The only references I found were about 6 years old, the original is probably [http://ubuntuforums.org/showthread.php?t=83973 this].<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:22, 16 December 2013 (UTC)<br />
<br />
:(I don't wanna know where you've downloaded the font you're using with your browser... XD )<br />
:Oh well, even though {{ic|Ctrl+Alt++}} was (luckily?) outdated in that context, that's certainly a big flaw in the style rule... What do we want to do, switch to the {{ic|Ctrl}}+{{ic|Alt}}+{{ic|+}} format? It would invalidate many of the style edits that have been done in the last months, but a bug is a bug ^^ Any better ideas?<br />
:About variable combinations, maybe we can just give some examples but leave the choice up to the editor?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:48, 17 December 2013 (UTC)<br />
<br />
::I would not change the rule for just one shortcut (resp. two: {{ic|Ctrl+Alt+-}}), converting it back would be really exhausting. If another instance appears, I'd create an exception for it. Or, even better, just link to an external documentation :P<br />
::Regarding the second problem I agree with leaving it up to the editor. Examples could be:<br />
::* press {{ic|Alt+.}} or {{ic|Alt+_}}<br />
::* press {{ic|Ctrl+Alt+F''N''}} to switch to the {{ic|''N''}}-th virtual console<br />
::i.e. basically use the full, expanded form or the [[Help:Style/Formatting_and_Punctuation#Pseudo-variables_in_file.2Fcommand_line_contents|pseudo-variables]].<br />
::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:12, 18 December 2013 (UTC)<br />
<br />
:::Well, let's just suspend this discussion until a similar problem is found again then, if ever. I'll think about closing it next time I'll come here to do some general clean up. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:25, 19 December 2013 (UTC)<br />
<br />
::::Putting spaces around the {{ic|+}} character would mitigate some of the confusion in the example Lahwaacz pointed out, but this would unfortunately require a lot of work to bring everything up to a new standard.<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:32, 11 January 2014 (UTC)<br />
<br />
:::::Um... {{ic|Ctrl + +}} doesn't look much clearer than {{ic|Ctrl++}} to me, if one day we'll need to change the rule for keys, we'll better do it the safest way, which probably is {{ic|Ctrl}}+{{ic|+}}, since as you point out it's going to be "a lot of work" in any case. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:51, 12 January 2014 (UTC)<br />
<br />
== Grammar errors throughout Help:Style ==<br />
<br />
I've found a large amount of grammar errors throughout [[Help:Style]], and it would be quite tedious to list a before and after for each one here in order to get them fixed. Would it be possible to either temporarily unlock [[Help:Style]] for editing (and closely monitor it for unauthorized changes), or if you don't want to unlock it for editing, should I just provide a pastebin with the revised wiki markup that you can copy/paste into the locked page? The downside to the latter option is that one really large change can be a pain to sort through in the history due to the lack of more verbose comments; although, if it's mostly simple grammar fixes, I guess this wouldn't be too big of a problem, as the change comments would likely be quite minimal.<br />
<br />
-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 03:41, 11 January 2014 (UTC)<br />
<br />
:It would be awesome if you could fix those errors, it will also be a good chance for me to improve my English: the article is unlocked now. Just make sure not to alter the explicit ''and'' implicit meaning of rules, e.g. [https://wiki.archlinux.org/index.php?title=Help:Style&diff=178056&oldid=178055] ;) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:16, 12 January 2014 (UTC)<br />
<br />
:I have a general question: what are the rules for using mdash ("&mdash;") vs. ndash ("&ndash;") in English literature? Is there supposed to be a space around them or not?<br />
:(I did not intend to challenge your work, I'm just curious - the rule is very likely to be different from those used in Czech...)<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:57, 11 February 2014 (UTC)<br />
<br />
::There is not supposed to be a ''full'' space around the em dash ("&mdash;") or the en dash ("&ndash;"). Ideally, the [https://en.wikipedia.org/wiki/Space_(punctuation)#Hair_spaces_around_dashes em and en dashes will be surrounded with a hair space], which is just wide enough to put a one pixel space between the dash and the adjacent characters, which makes it easier to read because the dash doesn't look like it's part of an adjacent character. I did not put hair spaces in my edits because I generally find it tedious to do.<br />
::As for when you should use the em dash vs. the en dash... the em dash is used for large pauses in speech or for side notes&#8202;&mdash;&#8202;notice the hair spaces around these em dashes&#8202;&mdash;&#8202;and the en dash is used for numeric ranges (e.g. 47&#8202;&ndash;&#8202;83).<br />
::The hyphen looks similar to the en dash (&nbsp;- &ndash;&nbsp;&nbsp;&larr; hyphen on the left, en dash on the right), but the hyphen is only supposed to be used between certain compound adjectives and nouns.<br />
::There's also the minus sign ("&minus;"), which looks very much like an en dash (&nbsp;&minus; &ndash;&nbsp;&nbsp;&larr; minus sign on the left, en dash on the right). It should only be used in mathematical formulas or when writing negative values (e.g. 47 &minus; 83 = &minus;36)<br />
::If you haven't noticed, I'm a bit of a typography geek. haha<br />
::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:02, 13 February 2014 (UTC)<br />
<br />
:::Thanks for this nice explanation! It is a shame that the wiki markup language does not have special syntax for this punctuation, entering the HTML codes is ''really'' PITA. There are some packages for LaTeX that translate "--" into en dash and "---" into em dash. But typographically, TeX is on completely different level than wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:08, 13 February 2014 (UTC)<br />
<br />
::::We could possibly add MediaWiki templates for the em dash and en dash. Adding a template for the minus sign seems like it might be overkill. For example, <nowiki>{{emdash}}</nowiki> or <nowiki>{{em dash}}</nowiki> would output {{ic|&.#8202;&.mdash;&.#8202;}} (without the dots, of course)<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 23:59, 18 February 2014 (UTC)<br />
<br />
:::::I say let's keep it simple, who would use those templates in practice? They would also go against our decision to e.g. use typewriter quotes instead of typographic, see [[Help:Style/Formatting_and_Punctuation#Quote_marks]]. As Lahwaacz mentioned, a wiki is not TeX, it's designed to keep source and rendered text similar, and punctuation templates would reduce readability of source text. MediaWiki takes care of translating source text characters into HTML entities when needed, and in my view we shouldn't try to bypass such feature except when really needed (see also [[Help:Template#HTML_entities]]). If you want to use some particular punctuation marks, IMHO you should enter them directly, possibly assigning them as special combinations to your keyboard map. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:00, 19 February 2014 (UTC)<br />
<br />
::::::Regarding source text readability, why not just input the unicode character itself — like this? (Notice that it works also for the hair spaces, though they are not very "hairy" in the source...) -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:01, 19 February 2014 (UTC)<br />
<br />
::::::I would use those templates. :)<br />
::::::I agree that <nowiki>{{em dash}}</nowiki> would be less readable than a directly-entered "—" character; however, <nowiki>{{em dash}}</nowiki> is a ''lot'' more readable than {{ic|&.#8202;&.mdash;&.#8202;}} (without the dots), which is why I support the idea. I feel that directly-entered em dashes with the surrounding hair spaces (using the Unicode characters directly) is less maintainable than <nowiki>{{em dash}}</nowiki> because subsequent edits may remove one or both of the hair spaces without editors realizing that they did so.<br />
::::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 01:14, 20 February 2014 (UTC)<br />
<br />
:::::::Ok, I admit that to me all this seems overly complicated as in not Simple, however, as [[Help:Style/Formatting_and_Punctuation#General_rules]] says, "for cases not covered in this guide, [[Wikipedia:Wikipedia:Manual of Style]] is the authority reference", and to me it seems very sensible to stick with that rule instead of attempting to create our own punctuation guides. In particular, [[Wikipedia:Wikipedia:Manual_of_Style#Punctuating_a_sentence_.28em_or_en_dashes.29]] says "do not use spaced em dashes", while they do have a <nowiki>{{spaced ndash}}</nowiki> template, so IMO that's what we should follow. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:21, 20 February 2014 (UTC)<br />
<br />
::::::::If we decide for the templates way, which subset of the [[Wikipedia:Category:Wikipedia_formatting_and_function_templates|Wikipedia formatting and function templates]] should be used on ArchWiki?<br />
::::::::I don't like the templates either, this had better be solved upstream (either directly in the parser core or via an extenasion. The only mention of upstream dealing with this I found is [https://meta.wikimedia.org/wiki/MediaWiki_feature_request_and_bug_report_discussion/Archive#.22Incorrect.22_quotes this] rather old discussion, so it's probably going nowhere. (Extending the parser should not be that hard, a couple of regular expressions should do it for the dashes -- I'm surprised that it's not done yet...)<br />
::::::::Suggestions so far: 1) use HTML entities (such as {{ic|&amp;mdash;}}), 2) use templates (such as {{ic|<nowiki>{{em dash}}</nowiki>}}), 3) use the Unicode characters directly, 4) use some extension (none found yet), 5) drop the typography rules completely (use plain spaced hyphen "{{ic| - }}" or commas) -- this could be called "wait for upstream to implement the necessary change" :P<br />
::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:43, 20 February 2014 (UTC)<br />
<br />
:::::::::Well, as I've said I'm for 3), with the possible advice of setting key combinations for the most frequent cases (e.g. {{ic|AltGr}} + {{ic|-}}<sup>I'm aware of [[#Problem_with_keyboard_keys_style|1]]</sup> for the em dash). Just out of curiosity, _personally_ I tend to use ~5) because in my native language all the cases where English requires dashes are covered by commas or parentheses, so I'll be seen rarely, if ever, using dashes in my contributions.<br />
:::::::::Even if there was an extension to parse "--" and "---", we'd still find resistance for having it installed in our wiki... Maybe upstream they're just waiting for your patch! ;)<br />
:::::::::About Wikipedia's "formatting and function" templates, for sure we're discarding the "function" ones, and about the others I'd say let's create them one at a time whenever one is needed, but only if method 3) and method 1), in that order, would require too much typing effort for that case.<br />
:::::::::For completeness' sake, there's also a suggestion 6) to use a (theoretical) external editor that turns "--" and "---" into proper dashes before sending the text to the server, and does the opposite when retrieving a page for editing.<br />
:::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:38, 21 February 2014 (UTC)<br />
<br />
:::::::::A little note, the Colemak layout already comes with en dash and em dash respectively preset to {{ic|AltGr+-}} and {{ic|AltGr+Shift+-}}. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:49, 10 June 2014 (UTC)<br />
<br />
== Rule suggestion: reference links ==<br />
<br />
First of all, sorry if there is already some similar rule about this, I don't know (yet) what I've forgotten since last year :/<br />
<br />
The suggestion:<br />
:"When adding troubleshooting sections to new problems, always add reference links into the article, whenever such links are available."<br />
<br />
(There is (at least) one implied meaning: "...and not just in the edit summary" :) )<br />
<br />
These links will be mostly links to our [https://bugs.archlinux.org/ bug tracker] or the [https://bbs.archlinux.org/ forums]. The rule should probably include some examples.<br />
<br />
The reason behind this is quite obvious: the users (and maintainers) will easily know if the problem is still valid or already fixed.<br />
<br />
Finally, some reference links for completeness: [https://wiki.archlinux.org/index.php?title=Chromium&diff=296005&oldid=295185], [https://wiki.archlinux.org/index.php?title=MPlayer&diff=296894&oldid=296809]<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:48, 11 February 2014 (UTC)<br />
<br />
:The style guide should be currently freely editable, even though discussing any changes beforehand is a ''must'' (so thank you for doing it). You can go ahead and add a few examples, with the only recommendation to be as synthetic as possible, in accordance with the rest of the guide. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:09, 12 February 2014 (UTC)<br />
<br />
== Slashes in titles ==<br />
<br />
It should be made clear that {{ic|/}} in page titles will create a subpage, even if the parent page does not exist. Different wording (which ''must'' exist) should be used in cases where the subpage is not desired. While everything is working OK on the web interface, missing this detail will make alternative interfaces, e.g. {{Pkg|arch-wiki-docs}}, quite confusing.<br />
<br />
Some infamous pages suffering from this issue:<br />
<br />
* [[:Category:Audio/Video]]<br />
* [https://wiki.archlinux.org/index.php//dev/shm /dev/shm] (no idea why [[/dev/shm]] does not work here, it does in [[XFCE simple Network Monitor applet#Prerequisites]])<br />
<br />
Additionally, I don't like the use of {{ic|/}} even in section titles, it just looks wrong: [https://wiki.archlinux.org/index.php?title=List_of_applications&oldid=301902#Scans.2FImage List of applications#Scans/Image].<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:42, 21 March 2014 (UTC)<br />
<br />
:Umm, technically what I just said is wrong - subpages are disabled in the Main namespace. See for yourself: add {{ic|<nowiki>{{SUBPAGENAME}}</nowiki>}} to [[systemd/User]] and preview, it will return "systemd/User" and not "User". (Also notice the small navigation link below the title in [[Help:Style/Formatting_and_punctuation]]) [[mw:Manual:$wgNamespacesWithSubpages|$wgNamespacesWithSubpages]] is probably set to default value in Arch Wiki configuration.<br />
:See also [[wikipedia:Help:Subpages#Slashes_in_article_titles]].<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:56, 22 March 2014 (UTC)<br />
<br />
::Yes, subpages are disabled in the Main namespace. [[:/dev/shm]] works in [[XFCE simple Network Monitor applet]] because that article is in the Main namespace and slashes are not specially interpreted there, while they are interpreted as relative (to the current page) links in the other namespaces like Help_talk, hence the red link since [[Help_talk:Style/dev]] doesn't exist. You must prefix a link like that with a colon in order to turn it into an "absolute" link, like {{ic|<nowiki>[[:/dev/shm]]</nowiki>}}.<br />
::That said, do you still support mentioning subpages in the guide? And how exactly? Also, would you forbid slashes in section titles? (I wouldn't, but I'm open for discussing as always)<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:11, 22 March 2014 (UTC)<br />
<br />
:::Well, we should either enable subpages ''everywhere'' (or just the Main namespace in addition to those currently enabled?), or avoid using the term "subpage" altogether: [[Help:Style#Title]], [[Help:Style#Kernel module operations]], ..., [[Talk:Arch systemd container]], [[Talk:Dm-crypt]], ... Is there too much harm in having [[S/KEY Authentication]] a subpage of [[S]]? Is there a way to disable the 'subpage' feature on specific articles? Alternatively, would it be even more confusing to rename the page to [[S KEY Authentication]]?<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:32, 23 March 2014 (UTC)<br />
<br />
::::I tend to be against real subpages in the Main namespace, as they would prevent the normal usage of slashes in titles, as you note too. Wikipedia has the same configuration by the way (but http://wiki.gentoo.org uses subpages).<br />
::::I understand that using the term "subpage" can be confusing if taken literally, but how would you call the practice of naming articles like "Beginners' guide/*", "List of applications/*" and so on?<br />
::::[[S/KEY Authentication]] as a subpage of [[S]] would create a confusing link at the top of the page, under the title (IMHO more confusing than the current usage of the "subpage" term).<br />
::::If there was a way to disable subpages per-page, it would be through [[mw:Help:Magic_words]], but it looks like there's nothing for that (yet?).<br />
::::Renaming articles like [[S KEY Authentication]] would mean enforcing the rule of avoiding slashes in titles, which is something I would be against... Unless we make use of DISPLAYTITLE to display the correct titles?<br />
::::Finally, I refuse to open a report to change the configuration of the wiki before {{Bug|35545}} is implemented >:( (Please, anybody reading here, vote for it)<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 21:54, 23 March 2014 (UTC)<br />
<br />
:::::Interesting, [http://wiki.gentoo.org/wiki/Boost/How_build_systems_find_boost] does not show the link below the title. Maybe because the parent page does not exist? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:51, 23 March 2014 (UTC)<br />
<br />
::::::Very interesting indeed, I've done a test here and the link does not appear if the super-page doesn't exist. This actually turns my preference towards enabling subpages also in the Main namespace. However we should patch LocalSettings.php for that, and {{Bug|35545}} is a blocker unfortunately. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 18:21, 24 March 2014 (UTC)<br />
<br />
:::::::I have misunderstood [[metawikipedia:Help:Link#Subpage_feature|Meta-Wiki]] entry yesterday; today I found the information in [[mw:Help:Link#Subpage_feature|MediaWiki]] too, but Meta-Wiki adds an interesting detail about breaking the breadcrumb links sequence on first non-existent page.<br />
:::::::[[Wikipedia:Help:Subpages#History_of_subpages|Wikipedia]] describes that they originally used subpages, but then switched to the disambiguation system, which probably lead to disabling subpages by default. We don't use disambiguations, so I don't see any further reason why the Main namespace should behave differently.<br />
:::::::{{Bug|35545}} is the blocker, but we won't get anywhere without submitting another bug - it could be the necessary catalyst. (About [https://wiki.archlinux.org/index.php?title=User:Kynikos&diff=306809&oldid=286042]: you've won two votes since yesterday :)<br />
:::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:31, 24 March 2014 (UTC)<br />
<br />
::::::::You're absolutely right, I'll let you open the report since the idea and the research are yours; it would be better if you could restate the supporting arguments there instead of linking here, and finally emphasize the fact that a patch will be provided if {{Bug|35545}} is implemented first (if we manage to have it fixed, it will be very very useful in the future).<br />
::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 18:08, 26 March 2014 (UTC)<br />
<br />
:::::::::Reported in {{Bug|39668}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 00:03, 29 March 2014 (UTC)<br />
<br />
::::::::::Added my vote. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:30, 30 March 2014 (UTC)<br />
<br />
=== Localized subpages ===<br />
<br />
If {{Bug|39668}} is implemented, we should probably rethink the rule for localized subpages in [[Help:I18n#Article_titles]]. The problem is that with {{ic|Title/Sub-page (Language)}} the breadcrumb links below the title will point to the English page instead of the localized one. {{ic|Title (Language)/Sub-page}} makes more sense wrt file system hierarchy anyway, so I would do it anyway. Alternatively we may go the [[Help_talk:I18n#Language_namespace.28s.29_in_place_of_suffixes.3F|language namespaces]] way, which should also solve this problem. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:30, 4 April 2014 (UTC)<br />
<br />
:My original intention behind the {{ic|Title/Sub-page (Language)}} style was to make it safer for [[Wiki Monkey]] to detect the language of an article by just looking at the end of the title, but I guess I might as well look for the tag anywhere in the title, and realistically it wouldn't give any troubles, so when {{Bug|39668}} is implemented we can indeed change the rule and rename the affected articles. The [[Help_talk:I18n#Language_namespace.28s.29_in_place_of_suffixes.3F|language namespaces]] way is still my long-term-preferred solution though. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 01:40, 5 April 2014 (UTC)<br />
<br />
== Formatting of references to man pages ==<br />
<br />
''[Moved from [[Help talk:Style/Formatting and punctuation#Formatting of references to man pages]] -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:24, 29 June 2014 (UTC)]''<br />
<br />
How should references to manpages be formatted? Possible formats:<br />
# {{ic|pacman}}(8)<br />
# {{ic|pacman(8)}}<br />
# ''pacman(8)''<br />
# .....see ''pacman'' manual.....<br />
#:or even maybe<br />
# {{ic|man 8 pacman}}<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:53, 28 June 2014 (UTC)<br />
<br />
:Ok, let's standardize this, I think the clearest is "... see {{ic|man pacman}} for details ...": the formatting complies with [[Help:Style/Formatting and Punctuation#CLI lines]] where it's already used as an example. I would leave the section number optional, it's quite rare that the same name is in two different sections, so we can recommend to specify it only in cases of ambiguity.<br />
:Let's read more opinions. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:34, 29 June 2014 (UTC)<br />
<br />
::I am ok with {{ic|man pacman}}.<br />
::Pros:<br />
::* Newbies who haven't encountered manpages yet (which I think is rare) can simply run the command and not wonder what pacman(8) is.<br />
::Cons:<br />
::* It implies that manpages should be read via {{ic|man}}. There are some great alternatives out there or may appear in the future. Of course users of these alternatives can run the equivalent command, but still.<br />
::Other thoughts: For popular manpage it's not very rare when one with same name is in different sections (crontab, man, intro, kill, link, locale, passwd, time, write, hostname). When a section isn't specified, this is the search priority:<br />
::* 1 or 8 - executables or system executables<br />
::* 3 - library calls<br />
::* 2 - kernel calls<br />
::* 5 - file formats<br />
::* 4 - special files (/dev)<br />
::* 6 - games<br />
::* 7 - misc<br />
::So we should be a bit careful when not specifying the section number. Though this shouldn't be a problem as the author has probably ran the command himself and means the first one in the priority list.<br />
::EDIT: If the user is using one of the alternative viewers and section number isn't specified, that can cause problems for multi-section pages. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 07:08, 29 June 2014 (UTC)<br />
<br />
:::It is good to consider users with alternative viewers as you do, but using one is an explicit choice. Hence, it seems fair to imply the user knows how to use it as a {{ic|man}} replacement. From the alternatives referencing the section in brackets only those having the section bracket outside the {{ic|ic tag}} would be workable. However, we generally want to give the man reference prominence and for that a "see {{ic|man passwd}} for options" is more prominent than a "see passwd(1) for options". That said, I'd personally like the non-ic version because it is a better textflow in my view. Plus the prominence the ic-tag gives is watered down the more it is used for peripheral commands. <br />
:::For the reason you give regarding the author (the editor deciding whether {{ic|man 5 passwd}} or {{ic|man 1 passwd}} is referenced) it seems safe to leave it optional like Kynikos suggests. <br />
:::To add another thought: In special cases it may even be helpful to reference it externally, e.g. like [http://linux.die.net/man/5/passwd passwd's manpage], particularly when it can be assumed the user has no access to it yet on the system itself. For example: we frequently have man references in the article preface, but referencing a package's man page at that early point (before the installation section) is not particularly reader friendly. The problem with external links is of course consistency, i.e. there are too many outdated external references. But most editors are well aware of that, I'd say. <br />
:::So, with the exception of special cases, I am +1 to Kynikos' suggestion if a rule is made, but like to add that I don't feel a need for it to be standardised. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:44, 29 June 2014 (UTC)<br />
<br />
::::Good point Indigo, we can't assume the manpage's package is installed. I'd say we can allow two versions of references to manpages:<br />
::::* If the package is probably not installed, use "see ''pacman'''s [https://www.archlinux.org/pacman/pacman.8.html manual] for details" with the recommendation to prefer linking to the official web representation of the manpage, if available.<br />
::::* If the package is probably installed, use "see {{ic|man 8 pacman}} for details", with the possibility to omit the section number when not ambiguous.<br />
::::* If the manpage is linked in a See also section, use the normal See also style instead (discussed in [[#Manpages in "See also" sections]]).<br />
::::Do you like it? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:19, 30 June 2014 (UTC)<br />
<br />
:::::Oh, fine with me. Thanks for working it out. I particularly like the recommendation towards referencing official package's web manpages too; very beneficial for content overall & software rolling forward. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:14, 30 June 2014 (UTC)<br />
<br />
::::::[https://wiki.archlinux.org/index.php?title=Mount&diff=330649&oldid=330646 This] is one of the reasons why external links for man pages can be harmful - some distributions may provide patched packages including patched man pages. As Arch provides mostly vanilla packages, the link should lead to upstream's page, which should be the most up to date version (also third-party sites may become outdated after some time). Perhaps this should be mentioned as well. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:59, 16 August 2014 (UTC)<br />
<br />
== Lists, colons, indentation ==<br />
<br />
As a continuation of [https://wiki.archlinux.org/index.php?title=Help_talk:Style&oldid=316593#Block_quotations Block quotations], let's clarify our position to multi-line blocks inside lists and indentation (definition lists without definition terms). I have slightly mentioned this in the previous discussion, and I'd like to finish it here.<br />
<br />
The markup lists are designed to be simple, and apparently are unsuitable for more complex lists, e.g. with multi-line blocks inside. [[wikipedia:Wikipedia:Manual_of_Style/Lists#Bulleted_and_numbered_lists|Wikipedia says]]: "Do not use lists if a passage is read easily as plain paragraphs." I think that most of the "incorrectness" on Arch wiki comes from disobeying this quote. We should probably recommend using the lists only in simple cases, one or two paragraphs in each item at most (use &lt;br> tags to separate them).<br />
<br />
Other common case, unfortunately falling into the non-simple category regarding markup, is that a [[template:note|note]] or [[template:tip|tip]] is presented inside a list. The "common" syntax has been<br />
{{bc|<nowiki><br />
* some text<br />
: {{Note|text to note}}<br />
</nowiki>}}<br />
but I've recently seen a number of edits changing it to<br />
{{bc|<nowiki>* some text {{Note|text to note}}</nowiki>}}<br />
which is something I don't like, because even though the latter renders correct HTML, it makes the wikitext unreadable. As much as we don't like it, definition lists without definition terms are a ''feature'', and the [[mw:Help:Lists|MediaWiki's manual]] is full of such tricks. To achieve a fully correct HTML output only with markup syntax, we would need to fix the parser/renderer anyway, so I think we should focus more on wikitext readability.<br />
<br />
The only way to achieve correct HTML, is to use HTML tags in wikitext, which brings me to the next problem: [https://wiki.archlinux.org/index.php?title=QEMU&diff=next&oldid=321689]. The edit clearly breaks the (future) rule "Do not use lists if a passage is read easily as plain paragraphs.", so the problem is reduced to usage of manual numbering - is it acceptable or do we tolerate HTML tags in such cases?<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:11, 29 June 2014 (UTC)<br />
<br />
:I agree, look at [https://wiki.archlinux.org/index.php?title=Compiz_%28Espa%C3%B1ol%29&oldid=273960 this page broken by a "Translateme" template inside a list]. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 08:30, 29 June 2014 (UTC)<br />
<br />
::I've used the {{ic|<nowiki>* some text {{Note|text to note}}</nowiki>}} trick several times myself, but after reading Lahwaacz's reasoning I won't anymore <small><small>(when I'll remember)</small></small>, as I agree completely: we should aim for the ''cleanest'' source text that results in the ''wanted'' appearance of the page. If the generated HTML is not correct it's indeed a problem of MediaWiki, we shouldn't try to work around it.<br />
::Yes, we should encourage preferring paragraphs or even subsections to lists with long/complex items. About ordered lists, manual numbering looks quite ugly to me, and I feel the same about mixing HTML and wiki markup: I think most (hopefully all) of the cases where it would be needed are better solved in some other way. For example in the QEMU case reported above, the items of that list don't need to be numbered, bullets or subsections should be used. Another notable example is [[Arch_packaging_standards#Submitting_packages_to_the_AUR]], where bullet points would be more appropriate.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:49, 30 June 2014 (UTC)<br />
<br />
:Maybe we can create a template for items? I mean something like this:<br />
:{{bc|<nowiki>* First item<br />
* Second item<br />
* {{Template_name|<br />
Third item<br />
<br />
{{Note|bla-bla}}<br />
<br />
Bla-bla-bla<br />
}}<br />
*Fourth item<br />
</nowiki>}}<br />
:And there will be a good readability of wikitext as well as correct indentations<br />
:-- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 07:47, 4 July 2014 (UTC)<br />
<br />
::This still seems too complicated to me. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:15, 5 July 2014 (UTC)<br />
<br />
::I don't think such template is possible, the blank lines would still break the list (test it for [[Template:bc]] without &lt;nowiki> tags). All the templates for lists on Wikipedia work the other way, template arguments are turned into list items. See for example [[wikipedia:Template:Ordered list]], but it relies on [[mw:Extension:Scribunto|Lua scripting]], which is not available on Arch wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:42, 5 July 2014 (UTC)<br />
<br />
== See also links ==<br />
<br />
This is a low priority discussion, more of a reminder, however I'd like to recommend a unified style for external links in See also sections, because at the moment the various articles are inconsistent about that. These are some options:<br />
<br />
* [https://www.archlinux.org/ Arch Linux home page]<br />
* Arch Linux home page: https://www.archlinux.org/<br />
* Arch Linux home page — https://www.archlinux.org/<br />
* https://www.archlinux.org/ — Arch Linux home page<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:36, 1 July 2014 (UTC)<br />
<br />
:I vote for the first style. It's compact and IIRC already more popular than the other styles. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:00, 1 July 2014 (UTC)<br />
<br />
::Agreed with axper, +1 to the first style. --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:28, 1 July 2014 (UTC)<br />
<br />
:::I like the first style too. Also, I think this is how the Wikipedia does it. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 20:35, 1 July 2014 (UTC)<br />
<br />
::::I'd prefer the first style too, but I forgot that links in See also section can be accompanied by descriptions, these are some examples of how the style can vary: [[Core utilities#See also]], [[Secure Shell#See also]], [[Systemd#See also]], [[KDE#See also]] (funny), [[Xfce#See also]], [[List of applications#See also]]. I haven't made up my mind yet. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:48, 5 July 2014 (UTC)<br />
<br />
::::Meahwhile I've run into a non-standard section in [[Cursor Themes]] and I've changed it [https://wiki.archlinux.org/index.php?title=Cursor_Themes&diff=323541&oldid=323304 like this]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:01, 6 July 2014 (UTC)<br />
<br />
:::::+1 for the first style. Yet the examples show how useful a description can be, I vote for making it optional. Having an optional description behind the link looks much neater as well imo, rather than trying to use the link title to transport it in those cases. <br />
:::::Focussing on the links in [[Systemd#See also]]: some are indeed a little dated (already), but it would be a pity to loose them. I was wondering for a moment whether it would make sense to foster grouping them, e.g. <br />
::::::* systemd tips and tricks: <br />
::::::** [http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions systemd FAQ]<br />
::::::** [http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks systemd tips and tricks]<br />
::::::** [http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]<br />
::::::* systemd project information: <br />
::::::** [http://0pointer.de/blog/projects/systemd.html Lennart's blog story] - on the motivation to create systemd <br />
::::::** ...<br />
::::::** [http://0pointer.de/blog/projects/systemd-update-3.html systemd status update 3] — (April 2012)<br />
:::::But then again there are few cases with that many links and the description can be useful/enough to transport that information too. Some sort of grouping happens automatically by editors keeping relevant links together and ordering most relevant (e.g. project home pages) first. <br />
:::::In my view the whole could be clarified by just appending some examples to [[Help:Style#.22See_also.22_sections]] ala: <br />
::::::Examples: <br />
::::::* [https://www.archlinux.org/ Arch Linux home page]<br />
::::::* [http://www.x.org/releases/current/doc/man/man3/Xcursor.3.xhtml man Xcursor] — for more information about cursors in X (supported directories, formats, compatibility, etc.).<br />
::::::* [http://0pointer.de/blog/projects/systemd-update-3.html systemd status update 3] — (April 2012)<br />
:::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:28, 11 August 2014 (UTC)<br />
<br />
== Preferred subpage method ==<br />
<br />
Options:<br />
<br />
* Page/subpage (examples: [[Perl Background Rotation/Tips]], [[List of applications/Utilities]])<br />
* Page - subpage (ex: [[Btrfs - Tips and tricks]]<br />
* Page subpage (ex: [[GNOME tips]], [[pacman tips]])<br />
* No subpages (using sections instead)<br />
<br />
See also: [[#Slashes_in_titles]] --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:16, 2 July 2014 (UTC)<br />
<br />
:I think, current method (number one) is good. The third one is bad (for example, it's very bad for ''List of applications Utilities''). You can add another method with colon symbol: ''Page:subpage''. But I'm ok with the first one -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 07:56, 4 July 2014 (UTC)<br />
<br />
::As [[mw:Help:Subpages|subpages]] are a feature of MediaWiki, the ''only'' way to have a full subpage experience is the first option. Unfortunately, it is currently disabled in the ''Main:'' namespace on Arch wiki (see [[#Slashes in titles]]). Until it is enabled, all options have equal weight, but using anything different than slashes does not make sense if we want to eventually switch to them. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:20, 4 July 2014 (UTC)<br />
<br />
:::As Lahwaacz says, using the slash form is the way to go for forward compatibility, do we want to write a rule and already start changing the existing non-compliant titles (e.g. [[pacman tips]])? The problem is that without the little navigation links under the title, it's not immediate to understand the meaning of the slash, especially for short titles, which at the moment look neater with a simple space. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:59, 5 July 2014 (UTC)<br />
<br />
::::My vote goes for option #4 (using sections like Wikipedia):<br />
::::# Doesn't to pollute the "Related articles" column with number_of_subpages<sup>2</sup> lines (or equivalent) with added complexity of maintaining all that<br />
::::# Doesn't pollute the category pages<br />
::::# It's easier to find information (i.e. {{ic|Ctrl+f}} or {{ic|/}} or by looking at TOC)<br />
::::# No confusion caused by non-existent separator character<br />
::::# Is just simple. Remember KISS? :)<br />
::::[[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:08, 8 July 2014 (UTC)<br />
<br />
:::::OK, let's compare us to Wikipedia (see [[wikipedia:Wikipedia:Subpages]] for reference). Basically, it forbids using subpages in the ''Main:'' namespace. The history section states, that subpages were once used to create hierarchies of articles, but then it was superseded by categories and disambiguations. On Arch wiki, the hierarchy of categories was designed as a ''tree'' (although in practice with some "converging branches", see [https://wiki.archlinux.org/index.php?title=Help_talk:Style&oldid=324150#Category_pages_-_tree_or_otherwise.3F #Category pages - tree or otherwise?]) and we don't use disambiguations at all. Unlike Wikipedia, so far this system works quite well on Arch wiki, which I think is mainly due to the type of content, amount of content and greater devotion and attention to detail of the [[ArchWiki:Maintenance Team|Maintenance Team]] :)<br />
:::::Sometimes an article is too long to be kept on just one page, and the easiest solution is to split some ''section'' into a separate article, which will effectively create a ''subpage''. I don't really see how this could be avoided without completely rewriting it, disambiguations or categories won't help here.<br />
:::::But I could agree that the usage of subpages should be regulated, for example [[PulseAudio/Troubleshooting]] would be good, while [[Kernels/Compilation/Traditional]] would be wrong (see the Wikipedia case). I don't know yet about [[Color Bash Prompt]] and something like [[Bash/Color prompt]].<br />
:::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:00, 9 July 2014 (UTC)<br />
<br />
::::::Well, solution #4 would be ideal, but in practice I think we can't really help splitting articles, both for length issues and because it's hard to understand when to stop merging articles back to their "parents". Take for example [[dm-crypt]]: it has several quite long subpages, would an article that merges all of them be clearer to read? I wouldn't see it as an improvement. And then why not merge [[dm-crypt]] and the others back to [[Disk encryption]]?<br />
::::::A subpage system is much more manageable, especially from the point of view of the maintainers, rather than the readers, so we just have to stick with it and make it as efficient and organized as possible.<br />
::::::@Lahwaacz How would you rename [[Kernels/Compilation/Traditional]]? [[Kernels/Compilation]] is the only child of [[Kernels]] (and currently only a redirect), so probably all those [https://wiki.archlinux.org/index.php?title=Special%3APrefixIndex&prefix=Kernels%2F&namespace=0 subpages] could be moved to [[Kernels/Traditional compilation]] and so on. Maybe we could limit the depth of subpages to just 1 in general?<br />
::::::About [[Color Bash Prompt]], I think its natural subpage version would be more [[Bash/Prompt color]], or, considering the actual content of the article, [[Bash/Prompt customization]] (I think we're using the AE spelling everywhere, but that's something else that's not regulated yet), [[Bash/Prompt style]] or similar.<br />
::::::-- 09:57, 10 July 2014 (UTC)<br />
<br />
:::::::Yes, [[Kernels/Traditional compilation]] looks good. About [[Color Bash Prompt]], I think that "color" is either a verb (as in "colorize") or an adjective, so I used it the same. But your alternatives are better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:21, 10 July 2014 (UTC)<br />
<br />
::::::::Thanks, what about limiting the depth of subpages to 1? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:13, 12 July 2014 (UTC)<br />
<br />
:::::::::I wouldn't mind more levels, provided that the first/previous level is wide enough. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:49, 12 July 2014 (UTC)<br />
<br />
== OK to put category pages in related articles list? ==<br />
<br />
Recently I made some edits which replaced links to multiple articles with a single link to a category page. That category page contains all those articles.<br />
* [[:Category:Hypervisors]]<br />
* [[:Category:Network managers]]<br />
<br />
Are people OK with this? If so, maybe edit [[Help:Style#Related_articles_box]] here to instead say:<br />
<br />
{{Box||<br />
* Provides a simple list of related internal pages.<br />
* Optionally included right below categories (or interlanguage links, or Article status templates, if present).<br />
* It can only be made of [[Template:Related articles start]], [[Template:Related]] and [[Template:Related articles end]]. See also the guidelines in those pages.<br />
* Non-English pages can make use of [[Template:Related2]] for translating the anchor text.<br />
* Use the [[#"See also" sections|"See also" section]] for a more complete and detailed list that also includes link descriptions and interwiki or external links.<br />
}}<br />
<br />
(change the word "article" to "page")<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:33, 10 July 2014 (UTC)<br />
<br />
:My first thought when reading this was "when the article is not included in the given category and it is still relevant, it should be included, otherwise not". On second thought, if the category is relevant enough, the article can be simple put into that category. The big problem is that related articles are at the top and related categories at the bottom.<br />
:We can either 1) leave pages at the top and categories at the bottom, 2) include every category into the 'Related articles' box at the top, 3) move the list of categories to the top (how?), 4) move the 'Related articles' box to the bottom (merge into 'See also' again).<br />
:Yep, so far I don't like either one of them for some reason or another...<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:25, 10 July 2014 (UTC)<br />
<br />
::About axper's proposed amendment, I agree, if a group of articles don't have a generic overview (e.g. unlike [[window managers]]), then linking to the category that groups them can be useful, if the edited article is not part of such category. Of course if the article itself is part of the category, there's the problem of duplicating the category link in the source text. This reminds me of an old idea of mine that I explained in [https://wiki.archlinux.org/index.php?title=Help_talk:Style/Article_summary_templates&oldid=287617#A_crazy_idea_.28about_Summary_templates.2C_Overview_templates_and_categories.29]: translated to the "modern" wiki, it could mean replacing the normal categorization system with a [[Template:Category]] to be added to the Related articles box, when present, so that the article gets categorized under some categories, but their links are also shown somehow in the floated box. For example:<br />
{{hc|Current system|<nowiki><br />
[[Category:Foo]]<br />
[[Category:Bar]]<br />
{{Related articles start}}<br />
{{Related|link}}<br />
{{Related articles end}}<br />
<br />
Body<br />
</nowiki>}}<br />
<br />
{{hc|New system|<nowiki><br />
{{Related articles start}}<br />
{{Category|Foo}}<br />
{{Category|Bar}}<br />
{{Related|link}}<br />
{{Related articles end}}<br />
<br />
Body<br />
</nowiki>}}<br />
<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:33, 12 July 2014 (UTC)<br />
<br />
:::The problem is that it involves more writing when there are no related articles (it is necessary to add <nowiki>{{Related articles start}}</nowiki> and <nowiki>{{Related articles end}}</nowiki> around the cats). Or would we use the current system for such pages? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:40, 12 July 2014 (UTC)<br />
<br />
::::I was just brainstorming, I'm not sure, maybe we could start using the RA box on every article? [[Wiki Monkey]] should have all the libraries needed to automate the migration, both for articles with an RA box and for those without, so the "extra writing" disadvantage wouldn't really apply. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:24, 13 July 2014 (UTC)<br />
<br />
== Convention on added/removed text in Hc Templates ==<br />
<br />
I just [https://wiki.archlinux.org/index.php?title=Nautilus&diff=prev&oldid=324433 used] the following way to clarify removed/added text in [[Nautilus#Use delete key to move to trash in Nautilus 3.6 and above]]:<br />
<br />
{{hc|~/.config/nautilus/accels|<br />
''<s>; (gtk_accel_path "<Actions>/DirViewActions/Trash" "<Primary>Delete")</s>''<br />
(gtk_accel_path "<Actions>/DirViewActions/Trash" "Delete")<br />
}}<br />
<br />
Is there already a policy on this? --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 23:29, 10 July 2014 (UTC)<br />
<br />
:Nope, there's no policy on that (yet?). Your version is certainly an improvement, compared to the previous {{ic|-+}} system, although in my opinion there's no need to add italic to the stricken line (keep it simple). What I think I've seen around more often, though, is a more verbose:<br />
<br />
::In {{ic|~/.config/nautilus/accels}}, replace:<br />
::{{bc|; (gtk_accel_path "<Actions>/DirViewActions/Trash" "<Primary>Delete")}}<br />
::with:<br />
::{{bc|(gtk_accel_path "<Actions>/DirViewActions/Trash" "Delete")}}<br />
<br />
:Your version has the advantage of using [[Template:hc]], thus making it ''visually'' clearer that those lines are two versions of the same line, and belong to the same file. The "verbose" version has the advantage of giving clearer ''written'' instructions about what has to be done.<br />
:Replacing lines doesn't seem to be very frequent in articles, maybe standardizing this would be too much. If we decided to use the "stricken" version, it would probably be worth adding a note in [[Help:Reading#Append, create, edit and source]].<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:30, 11 July 2014 (UTC)<br />
<br />
== Links to redirects ==<br />
<br />
I'd like to recommend avoiding links like {{ic|<nowiki>[[Xorg#Composite|AIGLX]]</nowiki>}} or {{ic|<nowiki>[[daemons|daemon]]</nowiki>}} and promote linking to redirects, e.g. {{ic|<nowiki>[[AIGLX]]</nowiki>}} or {{ic|<nowiki>[[daemon]]</nowiki>}}: this would have the advantage of:<br />
<br />
# making the source text simpler and easier to read<br />
# keeping track of the particular "reason" why a link is made, also grouping the various links by "reason" in WhatLinksHere pages<br />
# allowing quickly updating link fragments in case of section renames<br />
<br />
We may even encourage to create redirects like those when the alternative text could be used somewhere else.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:09, 12 July 2014 (UTC)<br />
<br />
:Exactly my thoughts, we've gotten too far in the "update link(s) (avoid redirect)" series of edits, which apparently set a bad example for others. Redirects are a feature and as such should not be avoided, except for the following cases (which I consider confusing):<br />
:# the titles differ only in capitalization<br />
:# the link is given in the 'Related articles' floating box<br />
:# two links to the same target are given next to each other, one of them goes over redirect<br />
:Also when a phrase {{ic|<nowiki>See [[Some page]] for details.</nowiki>}} is used, it should be a direct link, but this is not very confusing and likely depends on context, sometimes redirects might be desired even in this case.<br />
:There are also some tricks to save writing the anchor text in some cases, see for example [[Help:Editing#Pipe trick]]. Then there is the following syntax: {{ic|<nowiki>[[window manager]]s</nowiki>}}, which will result in [[window manager]]s, but this can be solved also with a redirect. (off-topic: does [[Wiki Monkey]] support this?)<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:21, 12 July 2014 (UTC)<br />
<br />
::I agree with the exceptions. About {{ic|<nowiki>See [[Some page]] for details.</nowiki>}}, I'd still consider my points 2) and 3), and maybe at least don't explicitly list the case among the exceptions (we'll have to write this rule more as a recommendation than an obligation anyway, so the editors will be able to decide case by case). We could also recommend the pipe or the suffix trick over redirects when it's possible to use them. (OT: nope, [https://github.com/kynikos/wiki-monkey/issues/186 #186] [https://github.com/kynikos/wiki-monkey/issues/188 #188]) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:21, 13 July 2014 (UTC)<br />
<br />
== Titles: singular or plural? ==<br />
<br />
Currently we have [[daemons]], [[List of applications]], [[:Category:Proxy servers]]... but also [[window manager]], [[display manager]], [[:Category:Mail Server]]... I'm for enforcing the plural version in all cases. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:26, 13 July 2014 (UTC)<br />
<br />
:I agree, plurals sound better, it's also how Wikipedia does it:<br />
:* [[Wikipedia:Wikipedia:Naming_conventions_(plurals)#Exceptions]]<br />
:* [[Wikipedia:Wikipedia:Category_names#General_conventions]]<br />
:[[User:Axper|axper]] ([[User talk:Axper|talk]]) 07:35, 13 July 2014 (UTC)<br />
<br />
== Questionable edits ==<br />
<br />
There are several kinds of questionable edits made almost regularly to the wiki. They are '''not''' breaking any rules (yet?), I just find them useless, counter-productive, or even annoying. I'd like to discuss them to see how others feel. Of course feel free to add a section of your own. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
=== Underscores vs. slashes in kernel module names ===<br />
<br />
Example: [https://wiki.archlinux.org/index.php?title=USB_storage_devices&diff=next&oldid=328933] vs. [https://wiki.archlinux.org/index.php?title=Advanced_Linux_Sound_Architecture&diff=311976&oldid=310951]<br />
<br />
From {{ic|modprobe(8)}}: ''"there is no difference between _ and - in module names (automatic underscore conversion is performed)"''. Not only the naming is inconsistent across the wiki, this could lead to edit wars.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:Let's just pick one style and go with it. I vote for undescores, since that's how {{ic|lsmod}} prints them, consistency would be nice.<br />
:I wouldn't consider these 2 edits questionable, rather it's lack of [[Help:Style]] rules about this particular subject.<br />
:[[User:Axper|axper]] ([[User talk:Axper|talk]]) 06:04, 10 August 2014 (UTC)<br />
<br />
::+1 for regulating this with underscores as per axper's lsmod argument. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
=== <s>Versioned links</s> ===<br />
<br />
Examples: [https://wiki.archlinux.org/index.php?title=USB_Flash_Installation_Media&diff=prev&oldid=323158], [https://wiki.archlinux.org/index.php?title=USB_Flash_Installation_Media&diff=prev&oldid=328011]<br />
<br />
I don't mind anybody updating the values, I just cannot understand why would someone update ''all'' of them regularly. It should be expected that these values will be outdated soon, the wording around them should make this clear.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:Well, this doesn't constitute a problem, right? If somebody updates them often I guess it's ok, it's not that we can write a rule like "don't update stuff too often" :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::I'm getting too lazy, and lazy people should not infect their surroundings, so I'll just close this... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:04, 16 August 2014 (UTC)<br />
<br />
=== Nice tables ===<br />
<br />
Examples: [https://wiki.archlinux.org/index.php?title=Xorg&diff=327837&oldid=327835], [https://wiki.archlinux.org/index.php?title=Repo-ck&diff=329471&oldid=329461]<br />
<br />
I think that we can afford to have ''nice'', colourful tables. The syntax for wikitables is not very well readable anyway, so a little of HTML will not hurt.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:Still, the HTML syntax is more complex than wiki-tables (and currently discouraged). You'd have to consider where "nice" fits in, compared to simplify editing content, where possible.<br />
:On the topic of HTML, I'd like to bring up a far more extreme example, [[Color_Bash_Prompt]], which seems nigh impossible to change in the standard editor ... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:34, 9 August 2014 (UTC)<br />
<br />
::The readability of wiki tables, both from wiki-text and rendered HTML, depends more on the amount of text inside the table, number of columns, (lack of) additional wiki formatting etc. Of course I agree that generally tables should be kept as simple as possible, but colours can improve the readability of HTML without substantial worsening of the wiki-text readability, so I'd say it's worth to use them.<br />
::And anyway, there is actually a wiki syntax available for specifying attributes for each cell, row, or table as a whole: [[wikipedia:Help:Table#Color.3B_scope_of_parameters]].<br />
::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:28, 9 August 2014 (UTC)<br />
<br />
:::On this topic, I'm for sticking to the no-HTML rule, but I'm perfectly fine with the native way of using CSS as reminded by Lahwaacz.<br />
:::Then there would be the template way of solving this problem, see [[ArchWiki talk:Reports#New templates]].<br />
:::About [[Color Bash Prompt]], that's an exception because HTML is the only way of presenting examples.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::::[[Wikipedia:Template:Table_cell_templates]] would do the trick. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:35, 19 August 2014 (UTC)<br />
<br />
=== Alphabetical order ===<br />
<br />
Example: [https://wiki.archlinux.org/index.php?title=Xorg&diff=prev&oldid=327850]<br />
<br />
Unless in lists (such as [[List of applications]]), alphabetical sorting of sections or other items is useless, I'd even say wrong. Alphabetical sorting is good for finding things, but we have full-text searching nowadays. Even ''chronological'' sorting (assuming that new sections are added to the bottom) is more useful for ''Troubleshooting'' sections.<br />
<br />
Also, have you ever read a book with chapters sorted alphabetically?<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:I think as long as the sorted sections are ''equivalent'' (as in, alphabetical order does not break logical order), you could probably make an argument for both. Should a rule for chronological sorting be found useful, however, I wouldn't object to it. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:41, 9 August 2014 (UTC)<br />
<br />
::Yes, I'd expect a section about a ''new'' bug I am looking a solution for to be at the end of the article. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 06:20, 10 August 2014 (UTC)<br />
<br />
:::First, the example edit should have been split (i.e. one section moved at a time).<br />
:::About the issue, I don't think that alphabetical order can make sense in Troubleshooting or Tips and tricks sections, since the first word of the headings is often incomparable (can be an article, a noun, etc.); chronological order would be better, for example a rule could recommend adding sections at the bottom (or top) of such section groups, unless some similar ones already exist, and in that case I guess keeping similar sections next to each other would be preferable.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::::+1, Lahwaacz is right. And one example for keeping similar sections next to each other: [[GNOME#Extensions]] -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 12:21, 20 August 2014 (UTC)<br />
<br />
=== Concision ===<br />
<br />
(without example)<br />
<br />
Several times recently I was ''amazed'' as to how can be a concise article made even more concise. I think that we need more ''precision over concision''. I think that the ''good'' wiki pages are usually verbose, as the topic is usually too complex to be described concisely. As tempting as it may be, having an expert making it more concise is not helpful for the majority of others.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:I think there's a difference between concision in ''style'' and concision in ''content''. Former is a matter of correct writing (convey information that helps understanding, not make it difficult); see [https://wiki.archlinux.org/index.php?title=Skype&diff=prev&oldid=328283] for a simple example. Latter should be avoided, and flagged (for example [https://wiki.archlinux.org/index.php?title=PPTP_Server&curid=9499&diff=329500&oldid=329283]) where appropriate. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:24, 9 August 2014 (UTC)<br />
<br />
::We can indeed put some recommendation like that in the guide, but this is something that the wiki staff will always have to keep an eye on, because experience is the only way to judge, case by case, what's too verbose and what's too concise. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::Thanks for this hint. I've never recognized concision as a [[wikipedia:Concision|term]] and always associated it only with removing of content, either large parts or nuances that might have been intended by the previous editor. Although the [[Help:Style#Language register|language]] should be concise, let's not take it too far. And especially watch out for the nuances. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:08, 10 August 2014 (UTC)<br />
<br />
== Hidden text ==<br />
<br />
:''moved from [[Talk:USB Flash Installation Media]] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:20, 15 August 2014 (UTC)<br />
<br />
Edition 330359, Using manual formatting in Windows.<br />
<br />
Regarding the following edition:<br />
https://wiki.archlinux.org/index.php?title=USB_Flash_Installation_Media&diff=330359&oldid=330302<br />
<br />
In the hidden text ("unhidden" by the edition #330359), I am not disputing the accuracy of the section.<br />
I am purposely leaving a hidden note for future editors.<br />
<br />
Someone could think that the referenced Note is not %100 technically accurate, and he would be correct.<br />
But the technical accuracy needs to be balanced with the real purpose of the wiki article: helping users with their task.<br />
<br />
In this particular case, a deeper technical explanation would make the referenced Note more accurate, but it would unnecessarily over-complicate the text for common users.<br />
<br />
In other words, by adding the hidden note I am "hinting" to potential editors to keep the section "as clear as necessary" for common readers/users so they would be able to perform the task, but without adding or correcting technical details that in practice would not further the real goal of typical readers/users. "As detailed as necessary, but not more than that".<br />
<br />
Therefore, I am inclined to undo the edition #330359 made by [[User:Lahwaacz]].<br />
Would you agree? {{Unsigned|18:51, 15 August 2014|Ady}}<br />
<br />
:HTML comments are neither mentioned in [[Help:Style]], [[Help:Editing]], or similar documents, and in general use of HTML is discouraged. See [[Help:Style#HTML_tags]].<br />
:And to be frank, a distinction between "readers" and "editors" is counterproductive. If a note is deemed not accurate, it should be removed, or if there's uncertainty, it should be mentioned on the talk page. Closing, feel free to re-open if there's doubts. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:37, 15 August 2014 (UTC)<br />
<br />
::Re-opening. IMHO, in certain cases there are differences between "readers" and "editors". The (previously hidden) text is useful for potential editors (those who (should) know enough about the subject), but it would be counterproductive for common users, who are just trying to follow practical steps.<br />
<br />
::I didn't use the hidden text formatting because of style, but because this is precisely the way to help editors without interfering with the normal flow of the text for readers.<br />
<br />
::The usage of <nowiki><!--Comment--></nowiki> for MediaWiki is explained, among other help pages, in http://en.wikipedia.org/wiki/Help:Hidden_text .<br />
::In the same page, http://en.wikipedia.org/wiki/Help:Hidden_text#Appropriate_uses_for_hidden_text :<br />
<br />
:::''Providing information to assist other editors...''<br />
<br />
::since the text would be counterproductive for readers, but useful for editors, I used the standard formatting for any MediaWiki.<br />
<br />
::Certainly the "accuracy" notice being displayed for common readers is counterproductive.<br />
<br />
::If I had to chose between:<br />
::* showing the "accuracy" notice to all readers; or<br />
::* not having the text at all;<br />
::and without the possibility to have the text as "hidden" to help editors, I would choose for not having the text at all, leaving the referenced Note alone.<br />
<br />
::Evidently I am of the opinion that the hidden text is the adequate method for its purpose.<br />
<br />
::Do you still disagree with leaving the text with MediaWiki's hidden formatting? [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 19:08, 15 August 2014 (UTC)<br />
<br />
:::Yes. ArchWiki "readers" are "editors" by definition. From [[The_Arch_Way]]:<br />
<br />
::::Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system. (...)<br />
<br />
::::This user-centric design necessarily implies a certain "do-it-yourself" approach to using the Arch distribution. Rather than pursuing assistance or requesting a new feature to be implemented by developers, Arch Linux users '''have a tendency to solve problems themselves and generously share the results with the community and development team – a "do first, then ask" philosophy.'''<br />
<br />
:::Either way, I see no argument to ''not'' use Talk pages for these purposes. A talk page doesn't interrupt the "normal flow" of reading, yet remains fully transparent. (PS: moving this discussion to [[Help talk:Style]]) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:19, 15 August 2014 (UTC)<br />
<br />
:::: IMHO the Talk pages are for discussions. The hidden formatting is for direct immediate help for a potential future relevant editor (who can clearly and immediately read the hidden text before saving his next related edition). Both methods are valid, because their respective goals and uses are different.<br />
<br />
:::: Even in The Arch Way, no one can know every single technical detail behind every single step. A reader follows the practical steps provided in an article. While the practical steps could be generally understood and successfully followed, there might be deeper technical reasons that are not necessarily understood or known by every reader/user. This is such a case.<br />
<br />
:::: In the particular section of the particular article we are discussing, I happen to know why there is a need for the referenced Note (as opposed to just skip it entirely). The referenced Note is adequate for users following the practical steps, but from a deeper technical level this referenced Note is only "%95" accurate.<br />
<br />
:::: For such "%5 inaccuracy" (which would require a lot of explanations in the wiki article), I'm not going to get into more discussions, specially considering that the practical steps for any user following the article are correct and adequate anyway.<br />
<br />
:::: As I mentioned before, if I had to choose between only two alternatives: either showing the "Accuracy" notice for everyone, or not showing the (previously hidden) text at all (not even for editors), I would choose the latter in this particular case. The reason is clear: the practical steps to be followed by users _are_ accurate.<br />
<br />
:::: The potential discussion about the usefulness of hidden text (aka comments) for editors in very specific cases is for mods, admins and alike. Regarding the particular edition that triggered this discussion about hidden text, I'll edit the wiki article so to delete the text; it will not be hidden, nor shown as "accuracy" notice. Thank you. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 21:27, 15 August 2014 (UTC)<br />
<br />
:::::The problem here is that you don't ''own'' that note, i.e. you have no special rights to indicate whether and how to modify it to other users. The same goes for everybody with every bit of content in every article. We could let users fill the pages with notes telling others how they'd like them to edit their original work, but the result would end up being a total mess, as can be imagined. IMO the only right you have is to discuss future edits (or intentions to edit) with the users who will show interest, and the only wiki way to do it is to add this article in your ''watchlist'' and watch it against counterproductive edits for as long as you are interested.<br />
:::::But where exactly is that note inaccurate? Because usually when you feel some deeper explanations are out of place in some article it's because that article's topic is quite different, so the details should belong somewhere else: is it something regarding [[syslinux]]? Because we have an entire article for it, maybe you could add what's needed there and simply link there from the note?<br />
:::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:59, 16 August 2014 (UTC)<br />
<br />
::::::We keep derailing further from the initial goal. No one claimed, suggested nor thought about owning anything. The purpose of leaving a comment for editors is to help them (editors) without "hurting" the normal flow for readers. MediaWiki uses this formatting as standard, precisely for the purpose I used it for (and I used it for what MediaWiki already considers as a valid, acceptable purpose for leaving hidden text).<br />
<br />
::::::Most frequently an editor won't read a Talk page for an edition where there is no "discussion" needed, specially in long pages with several sections (like it was in this case). The purpose of the "hidden" comment was to effectively "hint and help", not to impose or own anything.<br />
<br />
::::::In this particular case, some potential future editor might think "hmm, the technical background mentioned here is not %100 accurate, let's add several paragraphs of explanations". My "hint" attempted to say "please consider that, although the technical background is not %100 accurate here, the practical steps are clear and effective, there is no real need for additional background in this particular article, and the information already displayed is really needed". In other words, ''balance'' accuracy with clarity and effectiveness.<br />
<br />
::::::If a potential editor would want to ignore (and/or delete) the hint and add more information that is really not needed by the users to be able to follow the steps, then no one can stop him.<br />
<br />
::::::The edition from [[User:Lahwaacz]] said "''don't use HTML comments, they are not rendered''", and he added an "Accuracy" notice instead of the hidden text. Well, I purposely wanted the information to be not rendered for common readers, and my (previously) hidden text read "...it is accurate-enough so to be able to perform the task", which means the _opposite_ of showing the "Accuracy" notice. BTW, please note that [[Help:Style]] was not even mentioned in the reason for his edition.<br />
<br />
::::::As mentioned in http://en.wikipedia.org/wiki/Help:Hidden_text#Appropriate_uses_for_hidden_text , there are _appropriate_ uses for hidden text, and this was one of them.<br />
<br />
::::::Since the discussion has been moved from its original article, the focus has changed, from the technical details regarding "USB Flash Installation Media" and "Syslinux" steps, to "whether in this particular case the usage of 'comments' (aka hidden text) is adequate". In this particular case, I still consider that adding hidden text was appropriate, so to benefit both, readers and editors.<br />
<br />
::::::I have already eliminated the original source that triggered this discussion. I still think that there are valid reasons to use 'comments' in certain cases. Thank you. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 12:47, 16 August 2014 (UTC)<br />
<br />
:::::::There are several assumptions here:<br />
<br />
:::::::1. Editors tend to not read talk pages "where there is no discussion needed" (?)<br />
:::::::2. They particularly don't for "long pages"<br />
:::::::3. Editors always read pages in "Edit" mode<br />
<br />
:::::::I can't speak for others, but personally I have a "reactionary" editing style - I'm a "reader" (regular mode), and when I see something off or want to add something, I enter "Edit" mode. If I'm unsure, I '''collaborate''' edits by mentioning it in the article's talk page, or possibly an editor's talk page (including watchlist, as Kynikos mentioned). I also don't believe point 2 is fair; due to the close/delete policy of ArchWiki, talk pages are most often relevant to the current article and have a good overview. (Admittedly [[Help talk: Style]] is an exception, but that's expected)<br />
<br />
:::::::If you're sure something is ''glaringly'' inaccurate you use [[Template:Accuracy]], or simply fix the article directly (with the time spent to this discussion, it may have been done already...); as Kynikos said, this may include (links to) "outside" content. Otherwise, see the previous paragraph.<br />
<br />
:::::::Personally I'm still unconvinced of adding another method or rule. Re your BTW, not mentioning [[Help:Style]] was most likely an oversight (this is usually mentioned in edit summaries). Anyway, I'm bailing out... I'll see what comments others make. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:28, 16 August 2014 (UTC)<br />
<br />
::::::::@Ady (reopening): first of all I want to make clear that I didn't write the "own[ing]" argument in an accusing way, it was only meant to explain my point of view, I should have added a smiley at the end, I'll do it now :)<br />
::::::::More important, you said we "derail[ed] from the initial goal", but actually I asked you some questions that were very relevant and specific to your edit, and you haven't answered, so I'll paste them here again:<br />
::::::::Where exactly is that note inaccurate? Because usually when you feel some deeper explanations are out of place in some article it's because that article's topic is quite different, so the details should belong somewhere else: is it something regarding [[syslinux]]? Because we have an entire article for it, maybe you could add what's needed there and simply link there from the note?<br />
::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:49, 17 August 2014 (UTC)<br />
<br />
:::::::::@Kynikos, Since the discussion was moved, the focus changed from the more-technical matter to whether using hidden text was/is appropriate (in this particular case). Thus, I thought that perhaps answering those questions here would have been considered off-topic.<br />
<br />
:::::::::The referenced Note says "''The above step installs Syslinux's ldlinux.sys to the VBR of the USB partition, sets the partition as "active/boot" in the MBR partition table and writes the MBR boot code to the 1st 440-byte boot code region of the USB.''". As you can see, this Note is not part of a practical step (and therefore, a slight inaccuracy is likely not going to affect a typical reader following the instructions). Yet, there is a purpose for this Note.<br />
<br />
:::::::::Users kept asking (including to upstream Syslinux) whether they can skip part of the steps, and just copy over ldlinux.sys (for example, to either install or update SYSLINUX in their USB drives). Moreover, some users didn't even ask; they simply (over)wrote this file and they complained that SYSLINUX (and/or Arch) fails to boot. So the Note is there to prevent this type of behavior / confusion / repeated waste of time. This explains why deleting the referenced Note would not be wise.<br />
<br />
:::::::::About the minor inaccuracy... What the SYSLINUX installer does (when performing the specific steps exactly as described in the relevant section of the article) is to:<br />
:::::::::* copy ldlinux.{sys,c32};<br />
:::::::::* patch the VBR so it can point to the correct block in the device (so ldlinux.sys can be found);<br />
:::::::::* set the partition as "active/boot" in the partition table;<br />
:::::::::* write the MBR boot code to the 1st 440-byte boot code region of the USB.<br />
<br />
:::::::::I want to clarify that the above description is only relevant for the specific section we are referring to. The SYSLINUX/EXTLINUX installers perform different tasks according to different cases.<br />
<br />
:::::::::So, there is a minor (technical) background inaccuracy in the Note.<br />
<br />
:::::::::Considering the goal of this Note (as I already described it above) in the context of this particular section of this particular article, and considering that the practical steps provided in the article are not affected by this minor inaccuracy, I asked my self (at the time I performed other editions on the article) whether I should also edit the Note. Would I be actually helping a typical reader that is interested in following the steps? With the objective to balance between accuracy and clarity for the typical reader, I decided not to over-complicate the Note with excessive details that in practical terms only would make the section longer without improving the outcome.<br />
<br />
:::::::::Adding a link to the [[Syslinux]] article would not improve the practical experience / steps for the user in this case. If anyone wants to find more technical information, they don't need yet another link from that same article to the same Syslinux page. In this article, the typical reader is (and/or should better be) likely focused on the practical steps.<br />
<br />
:::::::::Thus, my "hint" was "''This note is not %100 technically accurate, but it is "accurate-enough" so to be able to perform the task.''". For the typical reader trying to follow the practical steps, the procedure is accurate and he will complete the task successfully, so adding an "Accuracy" box would be counterproductive.<br />
<br />
:::::::::Generally speaking, I think there are cases where adding 'comments' (aka hidden text) is adequate, but I am perfectly fine following the guidelines in [[Help:Style]]. Lahwaacz's edition formatted the "hint" as "Accuracy" box, going exactly in the opposite direction of what the hint itself was saying (or at least, against the original intention of the comment). This was not beneficial for users, so I deleted the box.<br />
<br />
:::::::::Slightly long to read (apologies), but I hope this clarifies the matter. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 10:45, 17 August 2014 (UTC)<br />
<br />
::::::::::I see, thanks for explaining, then why not make explicit the reason why the note is there (KISS), like:<br />
::::::::::{{Note|<br />
::::::::::* Make sure to run the above command in full, which installs Syslinux's {{ic|ldlinux.sys}} to the VBR of the USB partition, sets the partition as "active/boot" in the MBR partition table and writes the MBR boot code to the 1st 440-byte boot code region of the USB. Only copying the file, for example in an attempt to update an existing Syslinux installation, will result in an unbootable device.<br />
::::::::::* ...}}<br />
::::::::::This way nobody will see the note as useless and delete it.<br />
::::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:50, 19 August 2014 (UTC)<br />
<br />
:First, sorry for not including the link to [[Help:Style#HTML_tags]] in the edit summary, that was indeed my mistake.<br />
:In addition to the Alad's and Kynikos' replies above, I'd like to remind that ArchWiki is completely different project from Wikipedia and her sister projects, operated by [[wikipedia:Wikimedia Foundation|Wikimedia Foundation]]. ArchWiki has its own sets of rules, that are surely different from the WMF ones. The rule from [[Help:Style#HTML_tags]] regarding HTML comments stands, Alad and Kynikos provided the rationalization. Please respect this rule on ArchWiki.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:34, 16 August 2014 (UTC)<br />
<br />
== Hypertext metaphor interpretation ==<br />
<br />
Regarding [https://wiki.archlinux.org/index.php?title=Talk:VDR&diff=331548&oldid=331546], what is ok to duplicate and what not?<br />
<br />
The relevant rules in [[Help:Style#Hypertext metaphor]] are:<br />
<br />
:* Before writing a specific procedure in an article or describing something in particular, always check if there is already an article that treats that part in detail: in that case, link that article instead of duplicating its content.<br />
:* If the upstream documentation for the subject of your article is well-written and maintained, prefer just writing Arch-specific adaptations and linking to the official documentation for general information.<br />
<br />
''In my view'', the first one refers to internal articles only, so it doesn't apply here. The second should be regulating duplication of external sources. Now, I don't think we can consider https://wiki.debian.org/VDR as the "upstream documentation" for VDR, so I think duplicating the article here could be allowed, as Debian's wiki article (even if written by the same author) can't be considered a more reliable — or better maintained — source than this one. <br />
<br />
I've posted here because I want to discuss the interpretation of those rules in general, and possibly end up improving them to make their meaning clearer.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:57, 21 August 2014 (UTC)<br />
<br />
:You are right that there is no rule to address the issue ''directly'', hence my reply in [[Talk:VDR]] is probably an overstatement. Sometimes I link to [[Help:Style#Hypertext metaphor]] just so that the user gets the general idea.<br />
:To the interpretation of "Hypertext metaphor": IMV, "upstream/official documentation" in the second aforementioned rule ''can be'' "any external resource the editor is currently working with". For some projects, the notion of upstream/official documentation is pretty clear (e.g. [[i3]] with their [http://i3wm.org/docs/userguide.html userguide]), some projects have multiple high-quality "official documentations" (developers' blog posts, manpages, READMEs...), and some projects have none. In the last case it shouldn't matter if the source is hosted on some other distro's wiki or not, they should all have the same priority.<br />
:Regarding maintenance, [[VDR]] is not maintained [https://wiki.archlinux.org/index.php?title=VDR&diff=312049&oldid=239286 since 2012], while [https://wiki.debian.org/VDR Debian's] article has a [https://wiki.debian.org/VDR?action=info stable maintainer] (probably the same person as [[User:Cdwijs]]). This could be a reason both for and against porting the Debian's article here, but maintaining a single article is surely easier than maintaining two.<br />
:It is also questionable if porting an article from MoinMoin (used by Debian's wiki) to MediaWiki syntax can be called a duplication, but I still think it is useless from the reader's point of view.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:07, 21 August 2014 (UTC)<br />
<br />
==<s> Command line text </s>==<br />
<br />
I propose to dis-entangle the templates referenced in first two bullet points of [[Help:Style#Command line text]] as follows: <br />
* When using inline code ([[Template:ic]]), no prompt symbol is to be represented, but any notes about permissions must be added explicitly to the surrounding text.<br />
* When using block code (with [[Template:bc]] or a simple space character in front of each new command line), use {{Ic|$}} as a prompt for regular user commands; use {{Ic|#}} as a prompt for root commands. <br />
<br />
Further to that the bullet points following the note ''could'' be indented one more level to clarify they refer to block code. Having them on the same level as the first two makes it look like they are examples of inline code as well. <br />
<br />
Then there is [[#Ellipses_in_code_examples]] which could be added as a new bullet: <br />
* For code blocks based on a template, e.g. a configuration file, consider focussing the reader to relevant lines and ellipsing ({{ic|...}}) surrounding, non-relevant, code lines. <br />
<br />
in either [[Help:Style#Command line text]] or (better imo) [[Help:Style#Code formatting]]. <br />
--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 08:55, 24 August 2014 (UTC)<br />
<br />
: +1 for all of that -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 10:43, 26 August 2014 (UTC)<br />
<br />
::It's all implemented, thank you Indigo for preparing the text so I could practically just copy and paste it :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:02, 27 August 2014 (UTC)</div>Bwidhttps://wiki.archlinux.org/index.php?title=Help_talk:Style&diff=333611Help talk:Style2014-09-03T11:17:06Z<p>Bwid: /* Programming Languages - Introductory Paragraph */</p>
<hr />
<div>==Read this first==<br />
[[Help:Style]] is an official document of the ArchWiki, and it is actively monitored for malicious, unapproved, or poor quality edits. This is necessary to ensure sufficient stability over time, since frequent, undiscussed changes to its rules would defeat the purpose of the guide itself.<br />
<br />
It is probably needless to say that the active supervision of the article makes this very talk page the most important and effective place for discussing every possible improvement to the guide, from the correction of small typos to major changes like the introduction of new rules. Every report or discussion is welcome and will be answered as soon as possible. However, if an existing style rule is under dispute, its current state remains enforced until it is changed, if that ever happens.<br />
<br />
This guide was born after several months of discussions among the administrators and the most active contributors at the time, and it is a compromise among their ideas and those of who has been contributing until now. While new ideas and proposals that are coherent with the guide will probably be accepted and implemented, it is also likely that the requests that aim to radically change the way a particular style issue is already addressed will be discarded. We all must acknowledge the fact that it is reasonably unrealistic to think that all the ArchWiki users will ever completely agree over all the style rules, that is why it becomes necessary that final decisions be made by the administrators: we hope that this concept will be peacefully accepted by everybody, so that we can all collaborate in a more constructive way.<br />
<br />
Thank you for reading this notice and for contributing to the ArchWiki! -- [[ArchWiki:Administrators|The ArchWiki Administrators]] 21:27, 14 January 2012 (EST)<br />
<br />
{{Tip|A way to speed up the addition or modification of style rules is to provide some text that, if approved, can be directly copy-pasted in the guide, just like patches work for bug reports.}}<br />
__TOC__<br />
== Change Edit Summary label and possibility to make it mandatory ==<br />
<br />
All edits to articles should be accompanied by some words in the summary filed, answering the question "'''Why''' did you edit the article?". "What", "where", "when" and "how" are self-explained by the diff itself, it's redundant to add them. An explanation is not mandatory in talk pages, where the "why" should be already evident. Remember that links are allowed in the summary field, so it is allowed to point to an existing discussion. -- [[User:Kynikos|Kynikos]] 09:32, 3 May 2011 (EDT)<br />
<br />
Maybe we could submit a bug to request the change of the word "Summary:" to "Reason for editing:" next to the input in the edit page itself? -- [[User:Kynikos|Kynikos]] 11:33, 3 May 2011 (EDT)<br />
:+1<br />
:Would it go directly upstream? The Polish wiki has something like ''Summarize the changes [you've made to the article]''. Wikipedia has ''Edit summary <sub>(Briefly describe the changes you have made)</sub>''. They all deal with what is being changed, not '''why''' - we need to fix this :-) -- [[User:Karol|Karol]] 12:04, 3 May 2011 (EDT)<br />
::Done: {{Bug|24075}}, remember you can vote it. -- [[User:Kynikos|Kynikos]] 12:57, 3 May 2011 (EDT)<br />
:::Any wiki admin can change this message (aside: can you view [[Special:AllMessages]]?) I think it might be more fitting to include this as an addendum to the copyright notice instead (text above the summary field). Perhaps we should also consider making the edit summary mandatory (i.e. prevent saving with a blank summary). -- [[User:Pointone|pointone]] 22:55, 4 May 2011 (EDT)<br />
::::Nice, I can see that page, I didn't know that ^^ Maybe I should close the bug request then. Anyway I'm quite sure that ''only'' appending this recommendation to the copyright notice would make people start ignoring it very soon (as it happens with road signs eheh): I'm still in favour of changing the word "Summary", as it's misleading. Making the field mandatory could be a great idea instead, but for what I've seen until now, if the edit page returns an error, it forgets about the editing done, and it would be quite annoying (the textarea could be easily repopulated echoing $_POST['...'] instead of recovering the text back from the database; I have only tested this when trying to edit a page that has been edited by somebody else meanwhile). -- [[User:Kynikos|Kynikos]] 06:15, 5 May 2011 (EDT)<br />
::::(Well, doing it in javascript would solve the problem, though using JS is not very wiki-style it seems) -- [[User:Kynikos|Kynikos]] 06:17, 5 May 2011 (EDT)<br />
:::::When saving an edit that conflicts with another, your changes ''are'' saved. MediaWiki presents you with two text areas: one contains the page contents and the other contains your edit.<br />
:::::Either way, a quick Google search reveals [http://commons.wikimedia.org/wiki/User:DieBuche/forcesummary.js User:DieBuche/forcesummary.js] and [[Wikipedia:Wikipedia:WikiProject User scripts/Scripts/Force edit summary]] as two possible solutions. There also is a user preference option under '''Editing''' > '''Advanced options''' > '''Prompt me when entering a blank edit summary''' -- I wonder whether we can enable this option by default as a less-intrusive solution.<br />
:::::-- [[User:Pointone|pointone]] 09:16, 5 May 2011 (EDT)<br />
::::::Uhm it always looked like I lost my changes everytime I had edit conflicts (always easily recovered with the back button), anyway it could be that I didn't look well.<br />
::::::About the main topic, I would first try just to change the Summary text, anyway if you want to go the JS way immediately, do it in a way that the user understands that he has to answer the question "why", not "what", otherwise all edit summaries would probably be filled with "added section", "corrected code", "deleted section" and so on (well, those ''are'' summaries in the end, and that's what the form requests literally atm). -- [[User:Kynikos|Kynikos]] 11:07, 5 May 2011 (EDT)<br />
:::::::I think it's also OK to combine 'what' with 'why' e.g. '[https://wiki.archlinux.org/index.php?title=Arch_Based_Distributions_(Active)&diff=prev&oldid=139695 removed '''outdated''' links]'. I'm not a native English speaker, but it sounds more natural than 'links were outdated'. -- [[User:Karol|Karol]] 11:50, 6 May 2011 (EDT)<br />
::::::::Of course it's also ok, anyway I'm not a native speaker either, but if a label says "Reason for editing" it comes more natural to me to write "links were outdated". This system should also exploit a bit of psychology afterall. -- [[User:Kynikos|Kynikos]] 12:56, 6 May 2011 (EDT)<br />
:::::::::<facepalm> Of course you are absolutely right ... I - ummm - forgot that we wanted to change 'Summary' to 'Reason for editing'. Sorry about that. -- [[User:Karol|Karol]] 19:58, 8 May 2011 (EDT)<br />
:::Since the bug got closed as 'Upstream', do we go upstream with this? -- [[User:Karol|Karol]] 19:58, 8 May 2011 (EDT)<br />
::::I am curious whether this has been discussed upstream already... I have no problem with making the change on our end, since every wiki handles summary policy differently (as pointed-out above in examples). -- [[User:Pointone|pointone]] 22:46, 8 May 2011 (EDT)<br />
:::::Well you are the one in charge here, you can decide what to do now ;) -- [[User:Kynikos|Kynikos]] 05:53, 9 May 2011 (EDT)<br />
::::::The style part of this discussion has been implemented in the guide. I'd still be interested in changing "Summary" to "Reason for editing", anybody else? -- [[User:Kynikos|Kynikos]] 15:32, 21 September 2011 (EDT)<br />
:::::::Going upstream would benefit more that just our wiki, as mediawiki is a pretty popular piece of software. +1 from me. -- [[User:Karol|Karol]] 16:45, 21 September 2011 (EDT)<br />
::::::::The relevant system message is [[MediaWiki:Summary]]. I would suggest that the word "Summary" itself remain, as it is referenced in other locations and the documentation. My vote is for addition of an explanatory subtext à la Wikipedia. (Summary: <sub>(Briefly describe the changes you have made)</sub>). -- [[User:Pointone|pointone]] 13:50, 22 September 2011 (EDT)<br />
:::::::::Cooool, that's the way to go! +1000 XD<br />
:::::::::Some ideas:<br />
:::::::::*<sub>Briefly explain the reason for the changes you have made</sub><br />
:::::::::*<sub>Briefly explain the reason for your edit</sub><br />
:::::::::*<sub>Briefly explain the reason for your changes</sub><br />
:::::::::*<sub>Briefly explain the reason why you edited the page</sub><br />
:::::::::-- [[User:Kynikos|Kynikos]] 15:55, 22 September 2011 (EDT)<br />
::::::::::I think a combination of using explanatory text (I like something such as "<sub>Briefly explain the reason for your changes</sub>" from your suggestions), and investigating how to set "Prompt me when entering a blank edit summary" user option by default would make it more noticeable and be a great start here. [[User:Emiralle|Emiralle]] 12:56, 15 October 2011 (EDT)<br />
:::::::::::I'd like to make the edit summary strictly mandatory (meaning that a blank summary field won't allow submitting the edit): pointone mentioned some possible methods for doing this in the first part of the discussion, I'm just adding some more references as reminders (don't know exactly what to do with them yet... :P ): [http://www.mediawiki.org/wiki/Manual:$wgDefaultUserOptions] (see "forceeditsummary"), [http://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#Optional_additional_data], [http://www.mediawiki.org/wiki/Wikia_code/includes/EditPage.php]. -- [[User:Kynikos|Kynikos]] 15:01, 20 October 2011 (EDT)<br />
::::::::::::For the moment I've changed the label to:<br />
:::::::::::::[[Help:Style#Edit summary|'''Summary''']] <small>('''what''' you did and '''why''')</small>:<br />
::::::::::::as you can see when opening a page for edit, I hope it's ugly and annoying enough to be noticed by many >;)<br />
::::::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:37, 11 July 2013 (UTC)<br />
:::::::::::::The edit box has been moved to the right, so it's easy to spot that something's different. I like it, good job, Kynikos. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 19:14, 12 July 2013 (UTC)<br />
:::About making the ''Prompt me when entering a blank edit summary'' option enabled by default, this is what has to be done:<br />
:::# Have {{Bug|35545}} implemented<br />
:::# Edit [[MediaWiki:Missingsummary]] and make it more visible and formative<br />
:::# Add the {{ic|forceeditsummary}} option to the default user preferences as described in [[mw:Manual:$wgDefaultUserOptions]]<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:06, 13 July 2013 (UTC)<br />
<br />
==Article summary templates==<br />
See [[Help talk:Style/Article summary templates]].<br />
<br />
== Visited links color ==<br />
<br />
''[This sub-discussion stemmed as one of the several replies to [[#Style vs. Usability]]. Note that you may find some references to other sub-discussions that have been closed and removed. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:32, 27 July 2013 (UTC)]''<br />
<br />
Changing the color of visited links has been in my todo list for some time, maybe it's time to submit a bug for that: I'd like to see a purplish color, I tried something like <span style="color:#606;">#606</span>, <span style="color:#70b;">#70b</span>, <span style="color:#74b;">#74b</span>. More ideas? Objections?<br />
<br />
-- [[User:Kynikos|Kynikos]] 08:33, 19 January 2012 (EST)<br />
<br />
Note that interwiki links already become purple (albeit still too greyish?) when visited: [[wikipedia:Main Page]] '''[[wikipedia:Main Page]]'''. -- [[User:Kynikos|Kynikos]] 15:25, 24 January 2012 (EST)<br />
<br />
I'd also like to request that links remain bold even when they are in indented paragraphs ({{ic|#bodyContent dd > a {font-weight:bold;} }}?) -- [[User:Kynikos|Kynikos]] 11:46, 29 January 2012 (EST)<br />
<br />
:Completely agree. Also, I think, color should be different from one of interwiki links. --[[User:AlexanderR|AlexanderR]] 23:54, 29 January 2012 (EST)<br />
<br />
::Do you mean of a completely different color? Can you be more specific or give an example? In any case if there should be a difference in color among links, it should distinguish internal from external links (including interwiki).<br />
::However I think that black for normal text, blue for links (internal or external), purple for visited links and black on cyan for code may be already enough.<br />
::-- [[User:Kynikos|Kynikos]] 07:11, 31 January 2012 (EST)<br />
<br />
:::>> Do you mean of a completely different color?<br />
:::No, a bit darker shade than <span style="color:#606;">#606</span> (or, maybe even a bit more rich) would be perfect. --[[User:AlexanderR|AlexanderR]] 00:29, 4 February 2012 (EST)<br />
<br />
== Pkg and AUR templates: add icon, make them look different ==<br />
<br />
''[This sub-discussion stemmed as one of the several replies to [[#Style vs. Usability]]. Note that you may find some references to other sub-discussions that have been closed and removed. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:32, 27 July 2013 (UTC)]''<br />
<br />
More about visibility: we could <u>evaluate</u> (which means I'm not supporting yet this idea, i.e. I'm brainstorming) the possibility of adding a little inline package icon at the end of [[Template:Pkg]] and [[Template:AUR]] in a similar fashion to what happens with regular external links, that get a little arrow. Thoughts?<br />
<br />
I'm strongly against indentation as it won't work with installation requests that are included in longer sentences.<br />
<br />
-- [[User:Kynikos|Kynikos]] 08:33, 19 January 2012 (EST)<br />
<br />
If the icon for official packages is different from the one for aur packages, this may also let us avoid always adding "available in the [[official repositories]]" and "available in the [[AUR]]". -- [[User:Kynikos|Kynikos]] 11:46, 29 January 2012 (EST)<br />
<br />
:Well, if you find suitable icons. --[[User:AlexanderR|AlexanderR]] 23:54, 29 January 2012 (EST)<br />
:'''Edit:''' and develop alternative presentation for text browsers --[[User:AlexanderR|AlexanderR]] 23:54, 29 January 2012 (EST)<br />
<br />
::As an alternative to images, something like {{AUR|package}}<sup><small>[[AUR]]</small></sup> could be used. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:43, 24 July 2013 (UTC)<br />
<br />
:::We should also discuss, whether to change only AUR template, or also Pkg template. If we use {{AUR|package}}<sup><small>[[AUR]]</small></sup> style, I think it would be OK to let Pkg as is, but it would not allow to avoid "available in the [[official repositories]]". Adding "[[official repositories]]" into superscript for Pkg template is not possible because it's too long, perhaps some abbreviation could be introduced for this purpose.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:31, 24 July 2013 (UTC)<br />
<br />
::::The wording "available in the [[official repositories]]" was practically required only for consistency with the "available in the [[AUR]]" wording, but a link to [[official repositories]] is already in [[pacman]], and [[official repositories]] doesn't contain any useful information on how to install packages, as opposed to [[Arch User Repository]]. This is to say that we could leave [[Template:Pkg]] as it is, change [[Template:AUR]] to {{AUR|package}}<sup><small>[[AUR]]</small></sup> and stop requiring the "available in *" wordings.<br />
::::Note that just updating [[Template:AUR]] would make heaps of articles look weird, as they'd get two links to [[AUR]] very close to each other; a safer alternative could be:<br />
::::# copy [[Template:AUR]] to [[Template:AUR_temp]]<br />
::::# change all the current instances of [[Template:AUR]] to [[Template:AUR_temp]] using a bot<br />
::::# update [[Template:AUR]] to the new style<br />
::::# change all the instances of [[Template:AUR_temp]] back to [[Template:AUR]] manually, removing the "available in [[AUR]]" parts<br />
::::([[Template:AUR]] and [[Template:Aur]] are backlinked by almost [[Special:MostLinkedTemplates|1500 pages]] though)<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:03, 27 July 2013 (UTC)<br />
<br />
:::::I'm a bit late to the party, but I think this is the best and safest idea! As a side note, instead of {{ic|<nowiki>{{AUR_temp|package}}</nowiki>}}, we could maybe use something like {{ic|<nowiki>{{AUR|package|noicon}}</nowiki>}}, that can exist permanently, for use cases where the <sup><small>[[AUR]]</small></sup> is unwanted. -- [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 16:17, 9 July 2014 (UTC)<br />
<br />
::::::Unfortunately that's impossible to implement without any [[mw:Lua scripting|scripting]]. You'd need at least primitive condition clause to adapt the output based on whether the argument is defined or not. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:03, 9 July 2014 (UTC) <br />
<br />
:::::::Oh I'm sorry, I thought that functionality was built-in in MediaWiki. But if not, we could do {{ic|<nowiki>{{AUR|package}}</nowiki>}} and {{ic|<nowiki>{{AUR_noicon|package}}</nowiki>}}. -- [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 18:46, 9 July 2014 (UTC)<br />
<br />
::::::::I haven't tested it, but I think it would be possible to make [[Template:AUR]] hide the superscript with {{ic|<nowiki>{{AUR|package|}}</nowiki>}} (note the final pipe) or {{ic|<nowiki>{{AUR|package|noicon=}}</nowiki>}}, however for Simplicity I can't really think of any cases where we'd need that functionality.<br />
::::::::Putting that aside, I'd be ready to implement the plan I outlined above, but not before completing [[Help talk:Style/Article summary templates#Deprecation of summaries and overviews]] and [[Template talk:Wikipedia#Deprecation]].<br />
::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:25, 10 July 2014 (UTC)<br />
<br />
:::Other possibility could be to create separate templates for use in lists of applications, where the need to differentiate AUR and Pkg is obvious. I think it is not needed in article introductions etc., there are already phrases like "available in the [[official repositories]]" or "available in the [[AUR]]".<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:31, 24 July 2013 (UTC)<br />
<br />
::::I like the other idea more, for simplicity, however this alternative can of course be taken into consideration. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:03, 27 July 2013 (UTC)<br />
<br />
:::::It's a good solution to make it {{AUR|package}}<sup><small>[[AUR]]</small></sup>, because it has a good appearance and eliminates the need to write ''available in the *''. I think there's no need to use a separate template for [[List of applications]] or another articles, because such info (that package is in AUR) will never be reduntant. With this method we can leave [[Template:Pkg]] unchanged -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 15:01, 9 July 2014 (UTC)<br />
<br />
::::::Yeah, the idea about the separate template is discarded, let's focus on the other branch of this discussion above. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:30, 10 July 2014 (UTC)<br />
<br />
=== Recommended wording ===<br />
<br />
With a new template, offered by Kynikos, we must use another sentences to say about installing of packages. There're some options:<br />
<br />
# [[Arch User Repository#Installing packages|Install]] {{AUR|package}}<sup><small>[[AUR]]</small></sup><br />
# Install {{AUR|package}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup><br />
<br />
The second one have a link to section, not to a whole article.<br />
So, the first one is good, because that's the way of wording, recommended for packages from official repositories, but it has two links to the same article. The second one solves that issue, but in this case it will differ from wording of official packages. Opinions?<br />
<br />
P.S. Or maybe it will be better not to use a link to a particular section? If so, we can use the following wording:<br />
<br />
* [[pacman#Installing specific packages|Install]] {{Pkg|package}} - for official repositories<br />
* Install {{AUR|package}}<sup><small>[[AUR]]</small></sup><br />
<br />
-- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 13:02, 10 July 2014 (UTC)<br />
<br />
:I think we can indeed link to specific sections:<br />
:* {{ic|<nowiki>[[Install]] {{Pkg|package}}</nowiki>}} [[Install]] {{Pkg|package}}<br />
:* {{ic|<nowiki>Install {{AUR|package}}</nowiki>}} Install {{AUR|package}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup><br />
:Note the use of the [[Install]] redirect to pacman, which, besides being simpler, will allow easily updating all the links in case the relevant section in [[pacman]] is renamed; we may use it also for AUR packages, I think it wouldn't be confusing:<br />
:* {{ic|<nowiki>[[Install]] {{AUR|package}}</nowiki>}} [[Install]] {{AUR|package}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup><br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:54, 12 July 2014 (UTC)<br />
<br />
::I'm all for better templates, but keep in mind that {{ic|<nowiki><sup></nowiki>}} adds slight distance between previous and current lines, which looks slightly uglier to me. Compare:<br />
----<br />
::asdf safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad {{AUR|glfw3-git}} (CURRENT TEMPLATE) f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f {{AUR|glfw3-git}} asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads<br />
----<br />
::asdf safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad {{AUR|glfw3-git}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup> (NEW TEMPLATE) f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads {{AUR|glfw3-git}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup> fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad {{AUR|glfw3-git}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup> sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads<br />
::[[User:Axper|axper]] ([[User talk:Axper|talk]]) 05:13, 12 July 2014 (UTC)<br />
<br />
:::True, thanks for mentioning it, however it's easily fixed with {{ic|<nowiki><sup style="line-height:0;"></nowiki>}}:<br />
:::<div style="border:1px dashed black;float:left;width:200px;margin-right:1em;">neio ien eoi ien eioie neoi ien eoi {{AUR|tsra}}<sup style="line-height:0;"><small>[[Arch User Repository#Installing packages|AUR]]</small></sup> ne ooien neoiien neoi ioen neoi oien ne ineo ien</div> <div style="border:1px dashed black;float:left;width:200px;">neio ien eoi ien eioie neoi ien eoi {{AUR|tsra}} ne ooien neoiien neoi ioen neoi oien ne ineo ien</div> <div style="clear:both;"></div><br />
:::If I remember well it works on all the major browsers.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:49, 12 July 2014 (UTC)<br />
<br />
::::Yeah looks good! (on Firefox) [[User:Axper|axper]] ([[User talk:Axper|talk]]) 06:02, 12 July 2014 (UTC)<br />
<br />
::About that: {{ic|<nowiki>[[Install]] {{AUR|package}}</nowiki>}} [[Install]] {{AUR|package}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup><br />
::Oh no, think about ArchLinux's newcomers: they'll see a link to command {{ic|pacman -S ...}} (and it tells, that it's a command for installation of packages) and another link to a not-small list of incomprehensible actions. After that any newcomer will try to install AUR packages via {{ic|pacman -S}}<br />
::-- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 10:28, 16 July 2014 (UTC)<br />
<br />
:::Well this can make sense, besides users can learn to install AUR packages with makepkg -i which would avoid using pacman directly altogether. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:25, 17 July 2014 (UTC)<br />
<br />
== Daemons and modules ==<br />
===<s> Wording </s>===<br />
<br />
We need a more generic standard phrasing when requesting to "add daemons to the DAEMONS array..." (even avoid making reference to rc.conf, since [[Daemons]] links there already?) in the vein of what's been done with installation instructions, and point more clearly to [[Daemons]]. Similar problem with kernel modules and the MODULES array. Also the instructions for starting/stopping daemons and for adding/removing modules could be merged in the sentence.<br />
<br />
I'd like to start a brainstorming session here to find the right wording example(s) to put in the guide. Of course objections to the whole idea are still taken into consideration.<br />
<br />
We probably need a standard phrasing for immediate starting/stopping/loading/removing only, another standard for adding to DAEMONS/MODULES only and a third one for the cases where both immediate and automated action are recommended. I'll start with (I repeat, this is a brainstorming session):<br />
<br />
*"[[Daemons#Performing daemon actions manually|Start]] the {{ic|foobar}} daemon."<br />
*"[[Kernel Modules#Loading|Load]] the {{ic|foobar}} module."<br />
*"Add the {{ic|foobar}} daemon to the [[Daemons#Starting on Boot|DAEMONS]] array."<br />
*"Add the {{ic|foobar}} module to the [[Rc.conf#Hardware|MODULES]] array."<br />
*"[[Daemons#Performing daemon actions manually|Start]] the {{ic|foobar}} daemon and add it to the [[Daemons#Starting on Boot|DAEMONS]] array."<br />
*"[[Kernel Modules#Loading|Load]] the {{ic|foobar}} module and add it to the [[Rc.conf#Hardware|MODULES]] array."<br />
<br />
Note that if we solve the problem of links color and font-weight as explained at the bottom of [[#Style vs. Usability]], the links will always be blue/purple and bold, even in indented paragraphs. For now you can fake this effect by enclosing links in {{ic|<nowiki>'''</nowiki>}}.<br />
<br />
-- [[User:Kynikos|Kynikos]] 16:17, 31 January 2012 (EST)<br />
:* I moved this part to the separate section as this discussion is not directly related to "formatting bloat" but rather to unification of phrasing.<br />
:* Exact formatting depends on results of [[#Bold and italic]] discussion, so I propose to finish it before continuing this one.<br />
:>> objections to the whole idea are still taken into consideration<br />
:Well, I have already understood reasons for deprecating installation instructions and modules loading at startup/daemons autostart. All this is performed only once and there are a lot of troubles with giving command line snippets for this. But what's wrong with starting/stopping daemons? I'd better suggest to allow usage of snippets for this purpose but only for other reasons than creation of whole "Starting xxx manually" section, containing only that single line of code. IMHO, it is usually enough to mention existence and purpose of daemon in given package and providing link to [[Daemon]]. All daemons behave similarly, interaction with them in Arch is really simple; there is simply no need for adding same sections with same contents for ''every'' article. If writing snippet is really required to maintain workflow of step-by-step guide, then there is probably no need for restricting it (the same for loading/unloading) modules.<br />
:--[[User:AlexanderR|AlexanderR]] 19:44, 31 January 2012 (EST)<br />
::Eheh with "whole idea" I meant the idea expressed in the first paragraph, since I was asking for possible methods of applying it without apparently leaving room for objections. I admit it wasn't clear at all :) So, just to give you an answer, it would look a bit inconsistent to me to allow daemon starting/stopping instructions and not installation instructions, also because we should resort to using snippets like:<br />
:::You must now start the '''whatever''' daemon:<br />
:::{{bc|# rc.d start whatever}}<br />
::Which looks redundant to me, unless you wanted to suggest something like:<br />
:::Now run:<br />
:::{{bc|# rc.d start whatever}}<br />
::Which I like even less because it's not teaching anything, it just leads the inexperienced user to copy-paste the command, without thinking of what he's doing.<br />
::If you had something different in mind, just give an example. -- [[User:Kynikos|Kynikos]] 18:20, 3 February 2012 (EST)<br />
:::Again from [[PulseAudio]]:<br />
:::{{Box||If the D-Bus system daemon is not already running, start it:{{bc|# rc.d start dbus}}<br>PulseAudio can be started with:{{bc|$ pulseaudio --start}}<br>Or if you use X11:{{bc|$ start-pulseaudio-x11}}}}<br />
:::Lets break workflow:<br />
:::{{Box||PulseAudio depends on '''dbus''' [[daemon]], so first run it.<br>PulseAudio can be started with:{{bc|$ pulseaudio --start}}<br>Or if you use X11:{{bc|$ start-pulseaudio-x11}}}}<br />
:::What looks better? --[[User:AlexanderR|AlexanderR]] 00:37, 4 February 2012 (EST)<br />
::::This argument seems rather circular. I fully support the last comment by Kynikos. And personally, I would combine the first two sentences in AlexanderR's second example to something like:<br />
:::::Since PulseAudio depends on the {{ic|dbus}} daemon, [[Daemon|start]] dbus and then start PulseAudio:<br />
::::~ [[User:Filam|Filam]] 22:43, 4 February 2012 (EST)<br />
:::::Like this?<br />
:::::{{Box||Since PulseAudio depends on the {{ic|dbus}} daemon, [[Daemon|start]] dbus and then start PulseAudio:{{bc|$ pulseaudio --start}}<br>Or if you use X11:{{bc|$ start-pulseaudio-x11}}}}<br />
:::::[[Wikipedia:Looks|Looks]] nice, except usage of verb in link to [[daemon]] article: I [[Wikipedia:agree|agree]] with [[User:Vadmium]] about the fact that usage of such [[Wikipedia:WP:easter_egg|easter_egg]] links [[Wikipedia:can|can]] a bit annoying and sometimes even misleading.<br />
:::::PS I am not going to challenge already reached agreement on deprecation of daemon instructions, so please consider adding something useful to [[#Quoting and underlining]] and [[#Bold and italic]] discussions, so that we can continue this one. --[[User:AlexanderR|AlexanderR]] 00:40, 5 February 2012 (EST)<br />
<br />
::::::Since we mentioned services in [[Help:Reading]], using "easter egg" links in these cases should be ok, just like we're doing with installation instructions (we're not writing "install {{Pkg|somepackage}} with [[pacman]]"). I'm closing this discussion, the rest should be handled by the discussions below. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:01, 30 August 2014 (UTC)<br />
<br />
===<s> Daemon operations </s>===<br />
I'd like to suggest you / we add wording & style suggestions for systemd daemon operations to [[Help:Style#Daemon_operations]]. --[[User:Stefanwilkens]]<br />
<br />
:Agreed, can you start with an example of suggestions? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:58, 3 October 2012 (UTC)<br />
::Considering that giving direct examples that can be copy pasted is deprecated, I would suggest something like this:<br />
::Use [[Systemd#Using_Units|systemctl]] to enable <servicename> with <servicefile> during boot.<br />
::{{Note|Use [[Systemd#Using_Units|systemctl]] to enable GDM with {{ic|gdm.service}} during boot.}}<br />
::Or the more to the point:<br />
::<Action> <servicename> with <servicefile> using [[Systemd#Using_Units|systemctl]].<br />
::{{Note|Start GDM with {{ic|gdm.service}} using [[Systemd#Using_Units|systemctl]].}}<br />
::{{Note|Enable GDM at boot time with {{ic|gdm.service}} using [[Systemd#Using_Units|systemctl]].}}<br />
::Upon review of this, it seems that we may only have to adjust the references to rc.d and the old DAEMONS array from [[Help:Style#Daemon_operations]] and replace it with instructions fitting to systemd. For example:<br />
:::'''Daemon operations'''<br />
:::* The standard phrasing is a simple list of the daemons involved, possibly remarking dependencies or conflicts with other daemons, and a link to [[Daemon|Daemon]].<br />
:::* If a required action is not covered in [[Daemon|Daemon.]], it is acceptable to provide an example. Such an example should make use of the {{ic|systemctl}} command and provide a listing of the service files involved.<br />
:::* The Beginners' Guide and its subpages are the only exceptions to the rules above.<br />
::Just suggestions to get the ball rolling, nothing is worse that outdated documentation. --[[User:Stefanwilkens|stefanwilkens]] ([[User talk:Stefanwilkens|talk]]) 18:25, 14 October 2012 (UTC)<br />
<br />
:::Wrt [[#Passing arguments to systemd units: give example commands or not?]], here are a few suggestions to control [[systemd#Using units|instantiated units]]:<br />
:::{{Box||The {{ic|rfkill-block@.service}} [[systemd#Using units|template unit]] can be used to block given device type at boot, for example {{ic|rfkill-block@bluetooth.service}}.}}<br />
:::{{Box||To enable automatic switching of ''netctl'' profiles on a wireless interface, enable the {{ic|netctl-auto@.service}} [[systemd#Using units|template unit]]'s instance, for example {{ic|netctl-auto@wlan0.service}}.}}<br />
:::If the term "template unit" will catch on, we could create a redirect for it to simplify the linking.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:15, 23 August 2014 (UTC)<br />
<br />
::::I don't know, I've implemented my idea directly in [[Help:Style#Systemd units operations]] so we have something more tangible to work on (yes, I've also updated the heading, as the word "daemon" seems to have fallen a bit into disuse, replaced by "service", "unit" etc.).<br />
::::Regarding your proposal, I'd like to keep using the same kind of word as the anchor text for the link to [[systemd]], for consistency (i.e. the ''systemctl'' action). Then I'd avoid to use both "template" and "instance" in the same sentence, which sounds a bit redundant: it should be enough to say, more concisely, something like "an instance of {{ic|unit@.suffix}}".<br />
::::What do you think?<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:47, 26 August 2014 (UTC)<br />
<br />
:::::Your version is simpler indeed, I have no objections. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:08, 26 August 2014 (UTC)<br />
<br />
::::::Thanks, I'm closing this discussion then: perhaps the rules/examples may be improved further, but let's use new discussions for that when somebody comes up with a good idea. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:06, 30 August 2014 (UTC)<br />
<br />
=== Passing arguments to systemd units: give example commands or not? ===<br />
<br />
About [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=319448&oldid=319444], [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=next&oldid=319448] and [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=next&oldid=319449]: the current version makes it look like there is a file {{ic|dhcpcd@''interface_name''.service}} somewhere in the file system, the following sentence tries to explain that it is just an argument. IMO the original version was all clearer, more accurate and shorter, so I wonder if we can tolerate ''giving examples of how to manipulate systemd units taking arguments'', excepting it from the current rule. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:29, 26 June 2014 (UTC)<br />
<br />
:Are [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=321632&oldid=321570] and [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=321634&oldid=321632] clearer? Perhaps it would be easier to add a paragraph to [[systemd#Using_units]] explaining arguments, rather than add an exception. After all, many {{ic|.service}} files take arguments; on my install:<br />
<br />
:{{bc|<nowiki><br />
$ locate "@.service" | wc -l<br />
48<br />
</nowiki>}}<br />
<br />
:--[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:32, 26 June 2014 (UTC)<br />
<br />
::Oh well, the rule on daemons has certainly been one of the most controversial through time, it was originally designed for rc.d scripts [https://wiki.archlinux.org/index.php?title=Help:Style&oldid=163286#Daemon_operations] and after the switch to systemd it was only "translated", without doing any other adaptations.<br />
::systemd is certainly more powerful and we should start keeping that into account: I like Alad's idea, we should introduce unit '''instances''' (not "arguments") in [[systemd]], also for educational purposes, without excepting the style rule. I would seriously consider adding brief systemd guidelines to [[Help:Reading]] (or maybe just a link to [[systemd]]). Finally we should add well-designed wording examples to [[Help:Style#Daemon operations]] (see discussions above), like we've done for installation instructions: in case of unit instances we should use the word "instance" (or whatever word we decide to use) to link to the newly created section in [[systemd]].<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:18, 28 June 2014 (UTC)<br />
<br />
:::I was quite surprised to find out that the description of ''instantiated units'' is missing in [[systemd]] (I guess Archers are fine with man page). I agree that there should be at least a short intro, something we can link to. [https://coreos.com/docs/launching-containers/launching/getting-started-with-systemd/#instantiated-units This] looks nice, we could put together something similar. And use more external links of course, unfortunately I can't access [http://0pointer.de/blog/projects/systemd.html Lennart Poettering's blog], which as far as I remember described it quite well. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:59, 29 June 2014 (UTC)<br />
<br />
::::Lennart's site seems to go down intermittently, right now it works again... --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:10, 29 June 2014 (UTC)<br />
<br />
:::::Marked [[Systemd#Using units]] for expansion. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:58, 30 June 2014 (UTC)<br />
<br />
::::::I would leave it with a bullet for mentioning "instantiated" in that section and had a go on it (please check): [https://wiki.archlinux.org/index.php?title=Systemd&diff=331763&oldid=331698]. <br />
::::::Perhaps one of the instantiated ones most troublesome for users could be used as an item in [[Systemd#Troubleshooting]] to give a practical example? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:27, 21 August 2014 (UTC)<br />
<br />
:::::::I've improved the bullet point a bit and removed the Expansion flag.<br />
:::::::About [[Systemd#Troubleshooting]], would you use a unit instance in place of {{ic|systemd-modules-load}}? Maybe that can be discussed in [[Talk:Systemd]], honestly I'd be neutral about it.<br />
:::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:53, 23 August 2014 (UTC)<br />
<br />
::::::::I think that the current note is OK, thank you both for implementing it. From the first Kynikos' reply, we have yet to add recommended wording(s) to [[Help:Style#Daemon operations]]. I will add some suggestions for enabling instantiated units into [[#Daemon operations]].<br />
::::::::Wrt adding brief systemd guidelines into [[Help:Reading]], the same could be done for installing packages (and loading kernel modules and similar). Given that there will always be an explicit link to "[[pacman|install]]" or "[[systemd#Using units|enable]]" or "[[Kernel modules|load]]", things are pretty simple for the reader: they either know and do as being told, or just follow the link. [[Help:Reading#Append.2C_create.2C_edit_and_source|Editing config files]] is different in that there is not any accompanying link, hence the entry in [[Help:Reading]]. We could describe the Hypertext metaphor there, but I think that unlike editors, readers tend to follow it naturally.<br />
::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:27, 23 August 2014 (UTC)<br />
<br />
:::::::::Well, I was still thinking that some words in [[Help:Reading]] could fit the purpose of that article, also because it's linked from [[Main page#Help]] and it looked a bit incomplete without those basic examples, so I've gone ahead and added them, feedback is welcome. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:04, 25 August 2014 (UTC)<br />
<br />
::::::::::Reads perfect. Two small suggestions: under "$makepkg -si" I would add "to create and install the package with required dependencies.". Then, due to frequent usage, I would add ", ''enable''" to the first sentence [[Help:Reading#Control_of_systemd_units|here]]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:45, 26 August 2014 (UTC)<br />
<br />
:::::::::::Right, I've added "enable", but about makepkg I won't take action because [[Help:Reading]] is not really meant to give explanations, for that there are the main articles like [[AUR]] and [[makepkg]].<br />
:::::::::::Branch closed. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:20, 30 August 2014 (UTC)<br />
<br />
:Re Lahwaacz's original item I agree that using real examples instead of fictionary variables should avoid confusion, and now we have background explanation of "instances". I have edited the exemplified article with: [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=332005&oldid=322226], [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=332006&oldid=332005]. Works? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:39, 23 August 2014 (UTC)<br />
<br />
::Looks good to me, thanks for updating it. Regarding interface names, I'd suggest using the "old-school" names ({{ic|eth0}}, {{ic|wlan0}} etc.) as a transition between the predictable names ({{ic|enp0s25}} and similar/worse atrocities) and pseudo-variables ({{ic|''interface''}}, {{ic|''client_side_interface''}} etc.) because out of these three, the "old-school" names are probably the easiest to understand. If an appropriate note linking to [[Network configuration#Device names]] and stating the conventions '''for the given article''' is provided, even the users used to the predictable names should understand just fine. Also, [[Internet sharing]] uses a profound convention and introduces fictional interfaces {{ic|net0}} and {{ic|internet0}} to avoid long pseudo-variables like {{ic|''wan_interface''}} and {{ic|''client_side_interface''}}, so I don't mind fictional interface names either. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:19, 23 August 2014 (UTC)<br />
<br />
:::Well, one reason articles like [[Internet sharing]] introduced fictional names was also that they required interface persistence before predictable names were introduced. It's always context that makes one or the other seem more useful and, like you say, stating conventions. For example, I believe it's very important article's like the BG guide use predictable names, and explain them like they do. However, using those everywhere gets really awkwardly inconsistent over time, because if content gets gradually edited it's obvious that a command line output from editor2 will show another interface than the output in the paragraph above. That's another reason why I'm fully +1 with your suggestions. Let's see we keep it consistent in article context, conventions stated/crosslinked as applicable and prefer easy to grasp/recognisable short forms. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:46, 24 August 2014 (UTC)<br />
<br />
::::So, I'm a bit neutral here, do we want to explicitly invite to be consistent throughout each article without recommending any kind of name types? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:20, 30 August 2014 (UTC)<br />
<br />
=== Remove the rules on modules? ===<br />
<br />
The need for [[Help:Style#Kernel modules operations]] descends from the initscripts times, when the modules to be loaded had to be listed in rc.conf and it was too repetitive to always say how to edit that file. However, systemd and udev have made the need to explicitly load modules much more infrequent, so I'm wondering if we really still need those style rules, or if instead we can remove them and allow writing simple module loading instructions where specifically required. A link to [[kernel modules]] would still be encouraged by [[Help:Style#Hypertext metaphor]].<br />
<br />
In case it wasn't clear enough, I'm for removing the section.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:58, 26 August 2014 (UTC)<br />
<br />
== Better structuring ==<br />
<br />
IMHO, many parts of article can be safely moved to descriptions of corresponding templates. For example, information about [[Template:Keypress]] actually belongs to template itself rather than this style guidelines. I believe, most people look at template page before using it. What do you think? --[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
:Actually this idea would overlap with a larger project I've had in mind for some time now: merging editing and style guidelines consistently everywhere, and split them in several articles based on the various topics being dealt with. However I'd like to plan this carefully in advance, as it involves several pages, otherwise we risk increasing the mess instead of reducing it. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:04, 14 May 2012 (UTC)<br />
::> ..merging editing and style guidelines consistently everywhere, and split them in several articles based on the various topics being dealt with.<br />
::Sounds good. Note, that moving part of current content to templates can reduce overall size of all involved articles and possibly simplify further work. --[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
:See also [[#Help:Talk]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:11, 25 December 2012 (UTC)<br />
<br />
I was wondering, why the style guidelines are kept in the ''Help:'' namespace? I think that ''ArchWiki:'' would suit the rules better, then ''Help:'' could be reserved for examples, recommendations and guides (not guidelines). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:30, 23 August 2014 (UTC)<br />
<br />
:But with that reasoning nothing would be left in [[:Category:Help]] ^^ I know you're making the comparison with [[Wikipedia:Wikipedia:MoS]], I'm not aware of Wikipedia's policy about the scope of the two namespaces (but I've seen many Wikipedia:... articles under the Help category there, either directly or under a descendant, while Category:Wikipedia seems to contain articles that talk about Wikipedia in an encyclopedic way, and they're not in the Wikipedia's namespace).<br />
:In our wiki, I think we tend to have a correspondence (or redundancy) between the Help and ArchWiki namespaces and categories: Help is more for articles that are meant to show editors the proper way to contribute (and so yes, for coherence I'd move [[ArchWiki:Contributing]] there instead), and ArchWiki is more for articles that are about the wiki itself (not Arch Linux), including the pages that are used by the staff to ease maintenance. Also note that [[:Category:Help]] is a child of [[:Category:ArchWiki]].<br />
:In short, I'd leave Style where it is, and maybe I'd improve the correspondence between namespaces and categories, thus moving [[Table of contents]] under ArchWiki:, together with [[ArchWiki Translation Team]], and then there are also some uncategorized titles in [[Special:PrefixIndex/ArchWiki:]], we could consider categorizing them.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:20, 25 August 2014 (UTC)<br />
<br />
== Related links ==<br />
<br />
=== See also or Related in Article Summary? ===<br />
<br />
I think we'd better be coherent whether to keep links, references etc. either in a "See also" section at the bottom of the article, or in one (or more) boxes under the Article Summary at the top right of the article.<br />
<br />
See also [[#Article summary templates]].<br />
<br />
-- [[User:Kynikos|Kynikos]] 15:15, 21 September 2011 (EDT)<br />
<br />
:This is more a reminder than other, but I'm starting to like the idea of adding the rule to keep related ArchWiki articles in the Article Summary box only, and external links in See also sections only. Well, this way the "See also" default may even be changed (with bots, don't worry!) to a non-imperative, descriptive title like "Additional resources", "External links" or something like that. -- [[User:Kynikos|Kynikos]] 07:06, 14 December 2011 (EST)<br />
:Also remember that many external links in summaries can be found with [[Special:WhatLinksHere/Template:Article_summary_link]]. -- [[User:Kynikos|Kynikos]] 07:41, 24 January 2012 (EST)<br />
<br />
'''Advantages of links in See also:'''<br />
*There is more space for link descriptions<br />
*It is likely one will read or skim the article before actively looking for additional reading material. This naturally leaves the reader at the end of the article. It is convenient for the reader in this case if links are at the end of the article. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*It ''seems'' more common (elsewhere) to have links at the end of articles (when they are not inline with the rest of the text). Following common convention it may be better from a usability perspective. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*:Especially for people used to Wikipedia, which uses the same wiki software. [[User:Vadmium|Vadmium]] 11:12, 26 October 2011 (EDT).<br />
*I am not sure how much we care about this but it having the links at the end could be more friendly to small form factor screens and screen readers. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*As a section, "See also" gets its own TOC entry granting easy access from near the top of the article. Alternatively one may press the END key. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*More formatting options here than in summary. [[User:Emiralle|Emiralle]] 13:12, 15 October 2011 (EDT)<br />
*More inclined to put external, or less closely related stuff here. [[User:Emiralle|Emiralle]] 13:12, 15 October 2011 (EDT)<br />
*''See also'' section would not be skipped if you start reading the main text sequentially from the top. [[User:Vadmium|Vadmium]].<br />
*''[add more advantages...]''<br />
<br />
'''Advantages of links in Article Summary:'''<br />
*Immediately visible<br />
*Beyond some minor editing inconvenience, is there any real disadvantage of having the most ''interesting'' links in both locations? It could be advantageous for the reader to have some links in both locations. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*I think putting very closely related links in the summary gives the topic more cohesion, and as James Eder said, they could be included at the bottom as well. [[User:Emiralle|Emiralle]] 13:12, 15 October 2011 (EDT)<br />
*It would theoretically be more effective in preventing duplication of content within the wiki, as (unexperienced) editors would have a clearer view of the articles where related content could already exist (true especially with series (or "rings") of articles on the same subject). -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:46, 29 September 2013 (UTC)<br />
*''[add more advantages...]''<br />
<br />
=== Lists ===<br />
Inspired by [https://wiki.archlinux.org/index.php?title=Sound_system&curid=10626&diff=201543&oldid=197917], I was wondering if related links in "See also" sections or article summaries should be avoided if already present in the body of the article. I'd prefer having complete lists of related articles even if that implies duplicating some of them. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:09, 16 May 2012 (UTC)<br />
:> I'd prefer having complete lists of related articles even if that implies duplicating some of them<br />
:I'd prefer this way as well. Sadly listing ''all'' related articles may occupy most of vertical space, so there should be clear guidelines regarding choise of related links. And editors often don't have time to read even [[Help:Style]]... On the other hand, defining simple rule like "only links not present in text" can eliminate the very requirement for any additional rules. --[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
:: "only links not present in text" is too strict I think. Related links make some page more "visible" to readers. For example, I often click on them to learn more info about the same topic. But to be honest, I rarely click on the "in page links" even the links shown clearly in "See Also". They are much harder to be found and clicked. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 04:50, 19 May 2012 (UTC)<br />
<br />
=== Definition ===<br />
Inspired by [https://wiki.archlinux.org/index.php?title=Boot_Debugging&diff=prev&oldid=201554], I was wondering if we needed a definition of what are the conditions under which an article can be considered related to another one. Honestly I can't think of something suitable at the moment, if somebody has good ideas, they're welcome here. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:09, 16 May 2012 (UTC)<br />
:Few ideas:<br />
:* Alternatives to software, described in article<br />
:* Methods and techniques alternative to ones described in article<br />
:* Software <-> it's use case<br />
:* software/technique <-> it's developer<br />
:--[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
<br />
== Application name capitalization ==<br />
<br />
Which are the rules of capitalization of certain names? For LibreOffice there is no doubt, but for example is it 'bash' or 'Bash'? Probably the documented one is the preferable, so 'bash', 'Bash' when starts a sentence, aria2c everywhere. For zsh neither man pages are coherent. -- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 18:00, 19 May 2013 (UTC)<br />
<br />
:This topic is rather interesting: it's quite natural that we should follow the capitalization used in the upstream documentation, and this guide should probably mention it. I'd also like to remark whether the name should be always capitalized at the beginning of a sentence or not: honestly my position would be to still follow what the upstream documentation does.<br />
:In case the documentation is not coherent, I guess there's nothing we can suggest, except for being consistent throughout the article, _and_, if the application is mentioned in other articles, capitalization should be consistently based on the main article for that application (e.g. [[Bash]]).<br />
:Note that Bash is always capitalized in http://www.gnu.org/software/bash/<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:00, 22 May 2013 (UTC)<br />
::so Bash is written wrong in [[Help:Style#Shells]], (lol, forgive me :) ) -- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 10:29, 3 June 2013 (UTC)<br />
:::Ahah perfection is unreachable, you will always find something to report... Anyway in this case "bash" _would_be_ written "wrong" in [[Help:Style#Shells]] only if the above had already been enforced as a rule ;) (but I'll forgive you for this blunder, don't worry :P ) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:32, 3 June 2013 (UTC)<br />
<br />
::::I like the way the Git project uses both "Git" and "git" in their documentation based on what the author is referring to. They use "Git" when talking about the project/software generally, and they use "git" when referring to the ''compiled program used when running commands'' [https://github.com/git/git/blob/master/Documentation/CodingGuidelines#L313]. This style makes it quite easy to know whether to use "Bash" or "bash", etc.<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:42, 11 January 2014 (UTC)<br />
<br />
:::::That is certainly logical, with [[Help:Style/Formatting_and_Punctuation]] applied it would be "Git" (plain text, first letter uppercase) and "''git''" (italic, all lowercase). I believe that with proper context it would not be confusing, but for the controversial cases it's probably best to place a note with some explanation into the talk page, as it has been done for [[Btrfs]]: [https://wiki.archlinux.org/index.php?title=Talk:Btrfs&diff=291780&oldid=291779]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:09, 31 January 2014 (UTC)<br />
<br />
::::::In my view Git makes its spelling convention look more complicated than it is: IMHO it just says "always use 'Git', except when talking about the executable, which is a lower-case filename and couldn't be run otherwise". Anyway we could indeed enforce such a convention, but only for applications that A) don't have an official or common capitalization convention and B) are commonly run through an executable that has the same name as the application itself. This would of course settle Bash and Btrfs cases though. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:50, 1 February 2014 (UTC)<br />
<br />
==List of Applications and See also==<br />
# I suggest for lists like [[List_of_Applications/Multimedia]] to use capital letter for the first letter of the description, NO dots at the end (this behaviour seems to be preminent in Wikipedia) and to avoid totally articles ('A ..' is annoying). Is it ok?<br />
# In the same list it may be fair to put <nowiki>{{Grp|group}}</nowiki> beside items that have their one.<br />
# The '''See also''' section should be treated as above lists.<br />
<br />
-- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 18:00, 19 May 2013 (UTC)<br />
<br />
:I support 1. and 2. except for the dots at the end of descriptions, which I would require instead, since sometimes the App template has long descriptions, even made of several sentences, and including all the puntuation only omitting the final dot would look weird to me.<br />
:About 3. I don't understand what you mean, can you be more specific?<br />
:However I'm also wondering if these rules should be hosted here (if they refer to the use of Template:App) or in [[Talk:List of Applications]] (if they refer only to [[List of Applications]] and subpages).<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:23, 26 May 2013 (UTC)<br />
::About 3: I just mean that a section like [[Aria2#See_also]] must have capitalized letters and no dots (or whatever the standard would be).<br />
::About the hosting place: page like [[CD_Burning#Burning_CDs_with_a_GUI]] or [[Conky#AUR_packages]] are not directly related to [[List of Applications]], so I think it is worth to host a rule here. Plus this rule would apply also to any other list, like [[E4rat#Process]] --[[User:Flu|Flu]] ([[User talk:Flu|talk]]) 16:53, 26 May 2013 (UTC)<br />
:::Still about 3: I see, usually See-also links have much shorter descriptions, in that case I would apply a no-dot policy. Still open to more opinions though.<br />
:::Hosting place: a rule about lists of applications would probably best fit in [[Template:App]], also in light of my plans to decentralize style rules in general. A rule about See also sections would instead fit this guide indeed, at least for the moment.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:17, 28 May 2013 (UTC)<br />
<br />
== One link to the package in a paragraph is enough ==<br />
Do we need multiple links to the same package, wiki article etc. in the same paragraph? I understand that if the article is very long, the links may be used in different sections, but isn't "[[Arch_Boot_Process#Init_process|In the past, Arch used SysVinit as the init process. Now on new installs, Systemd is used by default. Existing SysVinit users are recommended to switch to systemd.]]" with 2 links to SysVinit and 2 links to systemd a bit too much? -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 23:15, 21 May 2013 (UTC)<br />
:First thing, probably in the title you mean links to articles in general, not only packages, right?<br />
:However, I definitely agree, I guess we could extend the rule to the same section or even the whole article, but I'd like to exclude some cases, like "See also" sections (see [[#Lists of related links]]), and to make the rule compatible with [[Help:Style#Official packages]] and similar.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:11, 22 May 2013 (UTC)<br />
::Just a reminder: this is affected by [[Help:Style/Formatting_and_Punctuation#First_instances]], not sure if it sould be mentioned directly on [[Help:Style]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:35, 1 September 2013 (UTC)<br />
<br />
== Red links ==<br />
Is creating links to nonexistent wiki articles a good thing because it encourages creation of [[Special:WantedPages|wanted pages]]? Is [https://wiki.archlinux.org/index.php?title=Getty&oldid=258135#Others this] OK or a bit too red? [https://wiki.archlinux.org/index.php/Template_talk:App One discussion] asserted that it's OK to create red links when using the app template, but I don't like them and I'd prefer not to litter articles with references to non-existent articles. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 13:12, 24 May 2013 (UTC)<br />
: I remember reading something like "Only add links to nonexisting wiki articles when you intend to add it soon". Forget where did I read it, but I agree with it. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 04:59, 25 May 2013 (UTC)<br />
::Fengchao's unknown quote doesn't sound bad to me either. This wasn't the central topic in [[Template talk:App#Introducing default argument]] by the way (that discussion is still valid, though). -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:39, 2 June 2013 (UTC)<br />
:::I removed the red links that were in English articles. Closing. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 22:03, 12 July 2013 (UTC)<br />
::::Reopening, I will add "Only add links to nonexisting wiki articles when you intend to add it soon" somewhere. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:16, 13 July 2013 (UTC)<br />
<br />
== Prefer linking to the article than to the package ==<br />
''When mentioning an application, prefer linking to its article, if existing, rather than directly to the package.'' -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:24, 28 May 2013 (UTC)<br />
:+1, apart from the standard "Download {{ic|foo}} from the official repos" and similar. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 13:27, 28 May 2013 (UTC)<br />
<br />
== git/vcs/source builds ==<br />
<br />
In some article there are source build instruction like [[Jumanji#Method_2:_From_Source]] and [https://wiki.archlinux.org/index.php?title=Logitech_Unifying_Receive&direction=prev&oldid=260677#From_AUR] or AUR git references like [https://wiki.archlinux.org/index.php?title=Bumblebee&oldid=259841#Installation]. I think they are pointless because:<br />
* of course you can build application on your own, there is no need to say that.<br />
* there is plenty of git/patched/vcs variants in AUR. One can decide to install them by their choice.<br />
What about a rule to forbid git/source references unless they are the only chance?<br />
::(oh no, another time) -- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 21:15, 2 June 2013 (UTC)<br />
:IMHO 'make && make install' instructions should go.<br />
:I have nothing against describing different AUR packages, whether VCS or not. PKGBUILDs are sometimes pretty complex and it's not obvious what's the difference between the various AUR versions of a package - if any.<br />
:Please sign your talk page edits [[Help:Discussion#Join_a_discussion]]. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 20:21, 2 June 2013 (UTC)<br />
::Yes, manual compilation instructions can be removed, but ''only'' when an AUR package is available. A rule may be added for this.<br />
::No, please don't remove links to "alternative" versions of packages in [[AUR]]; treat every AUR package as the others, there are not AUR packages more "official" than others: if they all install the same application, they _can_ (i.e. ''not'' _must_) be mentioned in the same article.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:05, 3 June 2013 (UTC)<br />
::Just mentioning a recent related example, [https://wiki.archlinux.org/index.php?title=Isync&diff=262333&oldid=253631], that I consider perfectly reasonable. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:10, 12 June 2013 (UTC)<br />
<br />
==<s> Ellipses in code examples </s>==<br />
<br />
Reminder: mention ellipsis as an allowed form of extraneous code in examples; [[Help:Style#Command line text]] is already forbidding comments next to commands and we're going to add formatting style rules for "pseudo-variables". -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:21, 13 July 2013 (UTC)<br />
<br />
:Implemented in [[Help:Style#Code formatting]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:03, 27 August 2014 (UTC)<br />
<br />
== Talk pages of redirects ==<br />
''[moved from [[User talk:Kynikos#Talk pages of redirects]] -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:01, 22 August 2013 (UTC)]''<br />
<br />
I didn't find any rule/official policy regarding talk pages of redirects, but you made me think about it.<sup>[https://wiki.archlinux.org/index.php?title=Special%3ALog&type=delete&page=Talk%3AXMPP]</sup> Should they be deleted (of course with the exception of actual issue regarding the redirect)? What would that mean for users (non-admins) - should the talk page be marked for deletion? Or explicitly ask some admin to delete it? Or should the talk page be just blanked (assuming all issues were solved before the redirect)? I ask because now I realized that I left quite a mess behind me when I redirected some pages. Anyway, I think that some specific instructions to either [[Help:Style#Redirect pages]] or [[Help:Editing#Redirects]] won't hurt. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:41, 21 August 2013 (UTC)<br />
<br />
:It's true, there's no written policy on this matter. Blanking a page is not an option in any case. If the redirect target's talk page doesn't exist, the redirect's talk page should be ''moved'' there (thus preserving its history); if the redirect target's talk page already exists, any redirect's talk page discussions should be ''merged'' there. The redirect's talk page can then be either redirected to the target's talk page (automatic when moving), fixing any double redirects, or marked for deletion ([[Help:Style#Redirect pages|without redirecting]]), fixing any backlinks first. Do we want to enforce only one of these possibilities or leave the choice case by case?<br />
:Note that admins and maintainers have the ability to move a page without leaving a redirect (deleting the original title), which could be taken into consideration, of course still taking care of fixing any backlinks first.<br />
:Finally, this could be part of an old [[User:Kynikos/Tasks#Ideas|idea]] of mine to create a page with checklists/procedures for the most common operations on articles, but that would be another discussion :)<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:19, 22 August 2013 (UTC)<br />
<br />
::Sorry for the delay, I've been inactive for a while.<br />
::Clearly discussions that become irrelevant after the redirect (like [[Talk:Tint#Merge with Tint2]]) can be removed. There may be discussions that are still relevant after the redirect (e.g. content related issues, can't find any good example right now), these issues should preferably be solved before redirecting the page, but that's up to the editor. I agree that remaining discussions should be moved/merged to the talk page of redirect target, so the question is what to do with the blank talk page?<br />
::I understand that there may be external websites with links to talk pages on ArchWiki and deleting the old talk page instead of redirecting it is rather unfriendly. On the other hand, those links are not used very often, especially for talk pages of some outdated, unmaintained or not very important pages. Just deleting it is much simpler (eh, the redirect is simple consequence of ''moving'' the whole talk page, but when the target talk page exists, deleting the source is simpler).<br />
::I also think that the redirects (at least for talk pages) should be deleted after some time, just another cleanup step. Especially if the main page was redirected for the second time (e.g. to fix some double redirect), take [[Talk:Suspend to Disk]] as an example.<br />
::Generally I don't have anything against redirects, it just makes the maintenance more difficult. For talk pages I think they are mostly superfluous.<br />
::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:11, 26 August 2013 (UTC)<br />
<br />
:::One problem I see is that deleting a redirecting talk page will make the history of any merged discussions inaccessible to normal users. Anyway this could be trivial, and recommending to mark the talk page for deletion would leave the final choice to an admin, who is supposed to be able to judge what's best to do, also considering redirecting as a possibility. So I've added a procedure to [https://wiki.archlinux.org/index.php?title=Help%3AEditing&diff=272909&oldid=272907 Help:Editing], do you like it? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:04, 28 August 2013 (UTC)<br />
<br />
::::Looks good. An idea: [[Help:Editing#Redirects]] could be split into three subsections, 1) what is a redirect, 2) when to redirect a page, 3) how to redirect a page. This could be applicable also to other procedures from your [[User:Kynikos/Tasks#Ideas|ideas]] and probably deserves separate discussion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:52, 28 August 2013 (UTC)<br />
<br />
::::As I said earlier, I messed up a few talk pages when redirecting. I've now marked most of them for deletion, see [[User:Lahwaacz#Messed_up_by_redirecting_the_main_page]] for quick list. The last one in the list, [[Talk:Map Custom Device Entries with udev]], contains two open discussions - I doubt they are still relevant, but I'll have to investigate further. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:47, 28 August 2013 (UTC)<br />
<br />
== Distinguish fragment identifier interwiki links? ==<br />
<br />
Similarly to [[#Visited_links_color]], can we distinguish [[Wikipedia:Fragment identifier|fragment identifier]] interwiki links (those written as {{ic|<nowiki>[[#foo]]</nowiki>}}) from other interwiki links (generally pointing to some other page)? I find something like {{ic|<nowiki>[[#PolicyKit authorization|PolicyKit authorization]]</nowiki>}} [https://wiki.archlinux.org/index.php?title=Libvirt&diff=next&oldid=274533] kind of confusing, it should be clear that the link points to a section on current page and not to separate page. Possibilities:<br />
<br />
# prefer {{ic|<nowiki>[[#foo]]</nowiki>}} instead of {{ic|<nowiki>[[#foo|foo]]</nowiki>}} - this does not solve something like {{ic|<nowiki>[[#Run daemon|run the daemon]]</nowiki>}}, also note that the fragment is case-sensitive<br />
# add some icon (superscript?) in front of/behind the link, I was thinking about the arrow shown in [https://wiki.archlinux.org/index.php?title=Help_talk:Style&action=history history pages] (but without the link to the section)<br />
# use some other color<br />
<br />
I'd vote for the second, it seems to be the most universal. Or does anybody have some other suggestion?<br />
<br />
(Looking at the second link in this post, something similar could be done for links to Wikipedia. In this case, I propose adding superscript {{ic|W}} behind the link.)<br />
<br />
Sorry if this has already been discussed somewhere else, I don't have the time to search it right now.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 7 October 2013 (UTC)<br />
<br />
:Talking of distinguishing links, external https links are not distinguished either:<br />
::[http://foobar.org http]<br />
::[https://foobar.org https]<br />
:Perhaps a bug?<br />
: -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:10, 10 October 2013 (UTC)<br />
<br />
::About the little icons next to links, I guess we could do it easily with CSS attribute selectors in the skin files.<br />
::About the https icon in particular, it looks it was disabled on purpose for some reason: [https://projects.archlinux.org/vhosts/wiki.archlinux.org.git/tree/skins/archlinux/arch.css] (line 67) I'd be curious to know why.<br />
::Of course to implement all this, a bug report should be opened and very likely patches should be prepared, so if you think you have the time to work on it, the project is at [https://projects.archlinux.org/vhosts/wiki.archlinux.org.git/] with links to clone the repo. I'd be interested in giving a hand of course :)<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:53, 10 October 2013 (UTC)<br />
<br />
:::Thanks for pointing me to the right direction, here's the commit about the https links: [https://projects.archlinux.org/vhosts/wiki.archlinux.org.git/commit/skins/archlinux/archlinux.css?id=e8b7a08c663a0fb392a24c67ec1dea59057f480a].<br />
:::Let's see if I can get to this again this weekend...<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:05, 10 October 2013 (UTC)<br />
<br />
::::I sent an email to [[User:Pierre|Pierre]] about the commit in November and did not receive any reply, so I submitted a bug report: {{Bug|38769}} - hopefully it won't be missed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:00, 2 February 2014 (UTC)<br />
<br />
:::::We'll see, I've submitted a patch, but unfortunately wiki bugs, even if easy to fix, have a [https://bugs.archlinux.org/task/35545 long life]... -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:17, 3 February 2014 (UTC)<br />
<br />
== Problem with keyboard keys style ==<br />
<br />
I could use some help with [[Keyboard Shortcuts]]:<br />
<br />
<s>According to [[Help:Style#Keyboard_keys]], {{ic|Ctrl}}+{{ic|Alt}}+{{ic|+}} should be {{ic|Ctrl+Alt++}}, but is that clear enough? (see [[Keyboard_Shortcuts#X11]])</s><br />
<br />
Also, what would be the preferred style for showing multiple shortcuts for some modifier combination?:<br />
<br />
* {{ic|Alt}}+{{ic|.}}or{{ic|_}}<br />
* {{ic|Ctrl}}+{{ic|Alt}}+{{ic|+}}/{{ic|-}}<br />
* {{ic|Ctrl}}+{{ic|Alt}}+{{ic|F1}}, {{ic|F2}}, {{ic|F3}}, ...<br />
<br />
(note: someone used {{ic|&uArr; Shift}} on that page, the arrow looks really funny :D )<br />
<br />
'''Edit:''' the {{ic|Ctrl+Alt++}} shortcut was either dropped from X or is specific to NVIDIA, so I've [https://wiki.archlinux.org/index.php?title=Keyboard_Shortcuts&diff=288958&oldid=288082 removed it] from the list of standard shortcuts. The only references I found were about 6 years old, the original is probably [http://ubuntuforums.org/showthread.php?t=83973 this].<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:22, 16 December 2013 (UTC)<br />
<br />
:(I don't wanna know where you've downloaded the font you're using with your browser... XD )<br />
:Oh well, even though {{ic|Ctrl+Alt++}} was (luckily?) outdated in that context, that's certainly a big flaw in the style rule... What do we want to do, switch to the {{ic|Ctrl}}+{{ic|Alt}}+{{ic|+}} format? It would invalidate many of the style edits that have been done in the last months, but a bug is a bug ^^ Any better ideas?<br />
:About variable combinations, maybe we can just give some examples but leave the choice up to the editor?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:48, 17 December 2013 (UTC)<br />
<br />
::I would not change the rule for just one shortcut (resp. two: {{ic|Ctrl+Alt+-}}), converting it back would be really exhausting. If another instance appears, I'd create an exception for it. Or, even better, just link to an external documentation :P<br />
::Regarding the second problem I agree with leaving it up to the editor. Examples could be:<br />
::* press {{ic|Alt+.}} or {{ic|Alt+_}}<br />
::* press {{ic|Ctrl+Alt+F''N''}} to switch to the {{ic|''N''}}-th virtual console<br />
::i.e. basically use the full, expanded form or the [[Help:Style/Formatting_and_Punctuation#Pseudo-variables_in_file.2Fcommand_line_contents|pseudo-variables]].<br />
::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:12, 18 December 2013 (UTC)<br />
<br />
:::Well, let's just suspend this discussion until a similar problem is found again then, if ever. I'll think about closing it next time I'll come here to do some general clean up. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:25, 19 December 2013 (UTC)<br />
<br />
::::Putting spaces around the {{ic|+}} character would mitigate some of the confusion in the example Lahwaacz pointed out, but this would unfortunately require a lot of work to bring everything up to a new standard.<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:32, 11 January 2014 (UTC)<br />
<br />
:::::Um... {{ic|Ctrl + +}} doesn't look much clearer than {{ic|Ctrl++}} to me, if one day we'll need to change the rule for keys, we'll better do it the safest way, which probably is {{ic|Ctrl}}+{{ic|+}}, since as you point out it's going to be "a lot of work" in any case. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:51, 12 January 2014 (UTC)<br />
<br />
== Grammar errors throughout Help:Style ==<br />
<br />
I've found a large amount of grammar errors throughout [[Help:Style]], and it would be quite tedious to list a before and after for each one here in order to get them fixed. Would it be possible to either temporarily unlock [[Help:Style]] for editing (and closely monitor it for unauthorized changes), or if you don't want to unlock it for editing, should I just provide a pastebin with the revised wiki markup that you can copy/paste into the locked page? The downside to the latter option is that one really large change can be a pain to sort through in the history due to the lack of more verbose comments; although, if it's mostly simple grammar fixes, I guess this wouldn't be too big of a problem, as the change comments would likely be quite minimal.<br />
<br />
-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 03:41, 11 January 2014 (UTC)<br />
<br />
:It would be awesome if you could fix those errors, it will also be a good chance for me to improve my English: the article is unlocked now. Just make sure not to alter the explicit ''and'' implicit meaning of rules, e.g. [https://wiki.archlinux.org/index.php?title=Help:Style&diff=178056&oldid=178055] ;) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:16, 12 January 2014 (UTC)<br />
<br />
:I have a general question: what are the rules for using mdash ("&mdash;") vs. ndash ("&ndash;") in English literature? Is there supposed to be a space around them or not?<br />
:(I did not intend to challenge your work, I'm just curious - the rule is very likely to be different from those used in Czech...)<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:57, 11 February 2014 (UTC)<br />
<br />
::There is not supposed to be a ''full'' space around the em dash ("&mdash;") or the en dash ("&ndash;"). Ideally, the [https://en.wikipedia.org/wiki/Space_(punctuation)#Hair_spaces_around_dashes em and en dashes will be surrounded with a hair space], which is just wide enough to put a one pixel space between the dash and the adjacent characters, which makes it easier to read because the dash doesn't look like it's part of an adjacent character. I did not put hair spaces in my edits because I generally find it tedious to do.<br />
::As for when you should use the em dash vs. the en dash... the em dash is used for large pauses in speech or for side notes&#8202;&mdash;&#8202;notice the hair spaces around these em dashes&#8202;&mdash;&#8202;and the en dash is used for numeric ranges (e.g. 47&#8202;&ndash;&#8202;83).<br />
::The hyphen looks similar to the en dash (&nbsp;- &ndash;&nbsp;&nbsp;&larr; hyphen on the left, en dash on the right), but the hyphen is only supposed to be used between certain compound adjectives and nouns.<br />
::There's also the minus sign ("&minus;"), which looks very much like an en dash (&nbsp;&minus; &ndash;&nbsp;&nbsp;&larr; minus sign on the left, en dash on the right). It should only be used in mathematical formulas or when writing negative values (e.g. 47 &minus; 83 = &minus;36)<br />
::If you haven't noticed, I'm a bit of a typography geek. haha<br />
::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:02, 13 February 2014 (UTC)<br />
<br />
:::Thanks for this nice explanation! It is a shame that the wiki markup language does not have special syntax for this punctuation, entering the HTML codes is ''really'' PITA. There are some packages for LaTeX that translate "--" into en dash and "---" into em dash. But typographically, TeX is on completely different level than wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:08, 13 February 2014 (UTC)<br />
<br />
::::We could possibly add MediaWiki templates for the em dash and en dash. Adding a template for the minus sign seems like it might be overkill. For example, <nowiki>{{emdash}}</nowiki> or <nowiki>{{em dash}}</nowiki> would output {{ic|&.#8202;&.mdash;&.#8202;}} (without the dots, of course)<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 23:59, 18 February 2014 (UTC)<br />
<br />
:::::I say let's keep it simple, who would use those templates in practice? They would also go against our decision to e.g. use typewriter quotes instead of typographic, see [[Help:Style/Formatting_and_Punctuation#Quote_marks]]. As Lahwaacz mentioned, a wiki is not TeX, it's designed to keep source and rendered text similar, and punctuation templates would reduce readability of source text. MediaWiki takes care of translating source text characters into HTML entities when needed, and in my view we shouldn't try to bypass such feature except when really needed (see also [[Help:Template#HTML_entities]]). If you want to use some particular punctuation marks, IMHO you should enter them directly, possibly assigning them as special combinations to your keyboard map. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:00, 19 February 2014 (UTC)<br />
<br />
::::::Regarding source text readability, why not just input the unicode character itself — like this? (Notice that it works also for the hair spaces, though they are not very "hairy" in the source...) -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:01, 19 February 2014 (UTC)<br />
<br />
::::::I would use those templates. :)<br />
::::::I agree that <nowiki>{{em dash}}</nowiki> would be less readable than a directly-entered "—" character; however, <nowiki>{{em dash}}</nowiki> is a ''lot'' more readable than {{ic|&.#8202;&.mdash;&.#8202;}} (without the dots), which is why I support the idea. I feel that directly-entered em dashes with the surrounding hair spaces (using the Unicode characters directly) is less maintainable than <nowiki>{{em dash}}</nowiki> because subsequent edits may remove one or both of the hair spaces without editors realizing that they did so.<br />
::::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 01:14, 20 February 2014 (UTC)<br />
<br />
:::::::Ok, I admit that to me all this seems overly complicated as in not Simple, however, as [[Help:Style/Formatting_and_Punctuation#General_rules]] says, "for cases not covered in this guide, [[Wikipedia:Wikipedia:Manual of Style]] is the authority reference", and to me it seems very sensible to stick with that rule instead of attempting to create our own punctuation guides. In particular, [[Wikipedia:Wikipedia:Manual_of_Style#Punctuating_a_sentence_.28em_or_en_dashes.29]] says "do not use spaced em dashes", while they do have a <nowiki>{{spaced ndash}}</nowiki> template, so IMO that's what we should follow. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:21, 20 February 2014 (UTC)<br />
<br />
::::::::If we decide for the templates way, which subset of the [[Wikipedia:Category:Wikipedia_formatting_and_function_templates|Wikipedia formatting and function templates]] should be used on ArchWiki?<br />
::::::::I don't like the templates either, this had better be solved upstream (either directly in the parser core or via an extenasion. The only mention of upstream dealing with this I found is [https://meta.wikimedia.org/wiki/MediaWiki_feature_request_and_bug_report_discussion/Archive#.22Incorrect.22_quotes this] rather old discussion, so it's probably going nowhere. (Extending the parser should not be that hard, a couple of regular expressions should do it for the dashes -- I'm surprised that it's not done yet...)<br />
::::::::Suggestions so far: 1) use HTML entities (such as {{ic|&amp;mdash;}}), 2) use templates (such as {{ic|<nowiki>{{em dash}}</nowiki>}}), 3) use the Unicode characters directly, 4) use some extension (none found yet), 5) drop the typography rules completely (use plain spaced hyphen "{{ic| - }}" or commas) -- this could be called "wait for upstream to implement the necessary change" :P<br />
::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:43, 20 February 2014 (UTC)<br />
<br />
:::::::::Well, as I've said I'm for 3), with the possible advice of setting key combinations for the most frequent cases (e.g. {{ic|AltGr}} + {{ic|-}}<sup>I'm aware of [[#Problem_with_keyboard_keys_style|1]]</sup> for the em dash). Just out of curiosity, _personally_ I tend to use ~5) because in my native language all the cases where English requires dashes are covered by commas or parentheses, so I'll be seen rarely, if ever, using dashes in my contributions.<br />
:::::::::Even if there was an extension to parse "--" and "---", we'd still find resistance for having it installed in our wiki... Maybe upstream they're just waiting for your patch! ;)<br />
:::::::::About Wikipedia's "formatting and function" templates, for sure we're discarding the "function" ones, and about the others I'd say let's create them one at a time whenever one is needed, but only if method 3) and method 1), in that order, would require too much typing effort for that case.<br />
:::::::::For completeness' sake, there's also a suggestion 6) to use a (theoretical) external editor that turns "--" and "---" into proper dashes before sending the text to the server, and does the opposite when retrieving a page for editing.<br />
:::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:38, 21 February 2014 (UTC)<br />
<br />
:::::::::A little note, the Colemak layout already comes with en dash and em dash respectively preset to {{ic|AltGr+-}} and {{ic|AltGr+Shift+-}}. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:49, 10 June 2014 (UTC)<br />
<br />
== Rule suggestion: reference links ==<br />
<br />
First of all, sorry if there is already some similar rule about this, I don't know (yet) what I've forgotten since last year :/<br />
<br />
The suggestion:<br />
:"When adding troubleshooting sections to new problems, always add reference links into the article, whenever such links are available."<br />
<br />
(There is (at least) one implied meaning: "...and not just in the edit summary" :) )<br />
<br />
These links will be mostly links to our [https://bugs.archlinux.org/ bug tracker] or the [https://bbs.archlinux.org/ forums]. The rule should probably include some examples.<br />
<br />
The reason behind this is quite obvious: the users (and maintainers) will easily know if the problem is still valid or already fixed.<br />
<br />
Finally, some reference links for completeness: [https://wiki.archlinux.org/index.php?title=Chromium&diff=296005&oldid=295185], [https://wiki.archlinux.org/index.php?title=MPlayer&diff=296894&oldid=296809]<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:48, 11 February 2014 (UTC)<br />
<br />
:The style guide should be currently freely editable, even though discussing any changes beforehand is a ''must'' (so thank you for doing it). You can go ahead and add a few examples, with the only recommendation to be as synthetic as possible, in accordance with the rest of the guide. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:09, 12 February 2014 (UTC)<br />
<br />
== Slashes in titles ==<br />
<br />
It should be made clear that {{ic|/}} in page titles will create a subpage, even if the parent page does not exist. Different wording (which ''must'' exist) should be used in cases where the subpage is not desired. While everything is working OK on the web interface, missing this detail will make alternative interfaces, e.g. {{Pkg|arch-wiki-docs}}, quite confusing.<br />
<br />
Some infamous pages suffering from this issue:<br />
<br />
* [[:Category:Audio/Video]]<br />
* [https://wiki.archlinux.org/index.php//dev/shm /dev/shm] (no idea why [[/dev/shm]] does not work here, it does in [[XFCE simple Network Monitor applet#Prerequisites]])<br />
<br />
Additionally, I don't like the use of {{ic|/}} even in section titles, it just looks wrong: [https://wiki.archlinux.org/index.php?title=List_of_applications&oldid=301902#Scans.2FImage List of applications#Scans/Image].<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:42, 21 March 2014 (UTC)<br />
<br />
:Umm, technically what I just said is wrong - subpages are disabled in the Main namespace. See for yourself: add {{ic|<nowiki>{{SUBPAGENAME}}</nowiki>}} to [[systemd/User]] and preview, it will return "systemd/User" and not "User". (Also notice the small navigation link below the title in [[Help:Style/Formatting_and_punctuation]]) [[mw:Manual:$wgNamespacesWithSubpages|$wgNamespacesWithSubpages]] is probably set to default value in Arch Wiki configuration.<br />
:See also [[wikipedia:Help:Subpages#Slashes_in_article_titles]].<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:56, 22 March 2014 (UTC)<br />
<br />
::Yes, subpages are disabled in the Main namespace. [[:/dev/shm]] works in [[XFCE simple Network Monitor applet]] because that article is in the Main namespace and slashes are not specially interpreted there, while they are interpreted as relative (to the current page) links in the other namespaces like Help_talk, hence the red link since [[Help_talk:Style/dev]] doesn't exist. You must prefix a link like that with a colon in order to turn it into an "absolute" link, like {{ic|<nowiki>[[:/dev/shm]]</nowiki>}}.<br />
::That said, do you still support mentioning subpages in the guide? And how exactly? Also, would you forbid slashes in section titles? (I wouldn't, but I'm open for discussing as always)<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:11, 22 March 2014 (UTC)<br />
<br />
:::Well, we should either enable subpages ''everywhere'' (or just the Main namespace in addition to those currently enabled?), or avoid using the term "subpage" altogether: [[Help:Style#Title]], [[Help:Style#Kernel module operations]], ..., [[Talk:Arch systemd container]], [[Talk:Dm-crypt]], ... Is there too much harm in having [[S/KEY Authentication]] a subpage of [[S]]? Is there a way to disable the 'subpage' feature on specific articles? Alternatively, would it be even more confusing to rename the page to [[S KEY Authentication]]?<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:32, 23 March 2014 (UTC)<br />
<br />
::::I tend to be against real subpages in the Main namespace, as they would prevent the normal usage of slashes in titles, as you note too. Wikipedia has the same configuration by the way (but http://wiki.gentoo.org uses subpages).<br />
::::I understand that using the term "subpage" can be confusing if taken literally, but how would you call the practice of naming articles like "Beginners' guide/*", "List of applications/*" and so on?<br />
::::[[S/KEY Authentication]] as a subpage of [[S]] would create a confusing link at the top of the page, under the title (IMHO more confusing than the current usage of the "subpage" term).<br />
::::If there was a way to disable subpages per-page, it would be through [[mw:Help:Magic_words]], but it looks like there's nothing for that (yet?).<br />
::::Renaming articles like [[S KEY Authentication]] would mean enforcing the rule of avoiding slashes in titles, which is something I would be against... Unless we make use of DISPLAYTITLE to display the correct titles?<br />
::::Finally, I refuse to open a report to change the configuration of the wiki before {{Bug|35545}} is implemented >:( (Please, anybody reading here, vote for it)<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 21:54, 23 March 2014 (UTC)<br />
<br />
:::::Interesting, [http://wiki.gentoo.org/wiki/Boost/How_build_systems_find_boost] does not show the link below the title. Maybe because the parent page does not exist? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:51, 23 March 2014 (UTC)<br />
<br />
::::::Very interesting indeed, I've done a test here and the link does not appear if the super-page doesn't exist. This actually turns my preference towards enabling subpages also in the Main namespace. However we should patch LocalSettings.php for that, and {{Bug|35545}} is a blocker unfortunately. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 18:21, 24 March 2014 (UTC)<br />
<br />
:::::::I have misunderstood [[metawikipedia:Help:Link#Subpage_feature|Meta-Wiki]] entry yesterday; today I found the information in [[mw:Help:Link#Subpage_feature|MediaWiki]] too, but Meta-Wiki adds an interesting detail about breaking the breadcrumb links sequence on first non-existent page.<br />
:::::::[[Wikipedia:Help:Subpages#History_of_subpages|Wikipedia]] describes that they originally used subpages, but then switched to the disambiguation system, which probably lead to disabling subpages by default. We don't use disambiguations, so I don't see any further reason why the Main namespace should behave differently.<br />
:::::::{{Bug|35545}} is the blocker, but we won't get anywhere without submitting another bug - it could be the necessary catalyst. (About [https://wiki.archlinux.org/index.php?title=User:Kynikos&diff=306809&oldid=286042]: you've won two votes since yesterday :)<br />
:::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:31, 24 March 2014 (UTC)<br />
<br />
::::::::You're absolutely right, I'll let you open the report since the idea and the research are yours; it would be better if you could restate the supporting arguments there instead of linking here, and finally emphasize the fact that a patch will be provided if {{Bug|35545}} is implemented first (if we manage to have it fixed, it will be very very useful in the future).<br />
::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 18:08, 26 March 2014 (UTC)<br />
<br />
:::::::::Reported in {{Bug|39668}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 00:03, 29 March 2014 (UTC)<br />
<br />
::::::::::Added my vote. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:30, 30 March 2014 (UTC)<br />
<br />
=== Localized subpages ===<br />
<br />
If {{Bug|39668}} is implemented, we should probably rethink the rule for localized subpages in [[Help:I18n#Article_titles]]. The problem is that with {{ic|Title/Sub-page (Language)}} the breadcrumb links below the title will point to the English page instead of the localized one. {{ic|Title (Language)/Sub-page}} makes more sense wrt file system hierarchy anyway, so I would do it anyway. Alternatively we may go the [[Help_talk:I18n#Language_namespace.28s.29_in_place_of_suffixes.3F|language namespaces]] way, which should also solve this problem. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:30, 4 April 2014 (UTC)<br />
<br />
:My original intention behind the {{ic|Title/Sub-page (Language)}} style was to make it safer for [[Wiki Monkey]] to detect the language of an article by just looking at the end of the title, but I guess I might as well look for the tag anywhere in the title, and realistically it wouldn't give any troubles, so when {{Bug|39668}} is implemented we can indeed change the rule and rename the affected articles. The [[Help_talk:I18n#Language_namespace.28s.29_in_place_of_suffixes.3F|language namespaces]] way is still my long-term-preferred solution though. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 01:40, 5 April 2014 (UTC)<br />
<br />
== Formatting of references to man pages ==<br />
<br />
''[Moved from [[Help talk:Style/Formatting and punctuation#Formatting of references to man pages]] -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:24, 29 June 2014 (UTC)]''<br />
<br />
How should references to manpages be formatted? Possible formats:<br />
# {{ic|pacman}}(8)<br />
# {{ic|pacman(8)}}<br />
# ''pacman(8)''<br />
# .....see ''pacman'' manual.....<br />
#:or even maybe<br />
# {{ic|man 8 pacman}}<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:53, 28 June 2014 (UTC)<br />
<br />
:Ok, let's standardize this, I think the clearest is "... see {{ic|man pacman}} for details ...": the formatting complies with [[Help:Style/Formatting and Punctuation#CLI lines]] where it's already used as an example. I would leave the section number optional, it's quite rare that the same name is in two different sections, so we can recommend to specify it only in cases of ambiguity.<br />
:Let's read more opinions. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:34, 29 June 2014 (UTC)<br />
<br />
::I am ok with {{ic|man pacman}}.<br />
::Pros:<br />
::* Newbies who haven't encountered manpages yet (which I think is rare) can simply run the command and not wonder what pacman(8) is.<br />
::Cons:<br />
::* It implies that manpages should be read via {{ic|man}}. There are some great alternatives out there or may appear in the future. Of course users of these alternatives can run the equivalent command, but still.<br />
::Other thoughts: For popular manpage it's not very rare when one with same name is in different sections (crontab, man, intro, kill, link, locale, passwd, time, write, hostname). When a section isn't specified, this is the search priority:<br />
::* 1 or 8 - executables or system executables<br />
::* 3 - library calls<br />
::* 2 - kernel calls<br />
::* 5 - file formats<br />
::* 4 - special files (/dev)<br />
::* 6 - games<br />
::* 7 - misc<br />
::So we should be a bit careful when not specifying the section number. Though this shouldn't be a problem as the author has probably ran the command himself and means the first one in the priority list.<br />
::EDIT: If the user is using one of the alternative viewers and section number isn't specified, that can cause problems for multi-section pages. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 07:08, 29 June 2014 (UTC)<br />
<br />
:::It is good to consider users with alternative viewers as you do, but using one is an explicit choice. Hence, it seems fair to imply the user knows how to use it as a {{ic|man}} replacement. From the alternatives referencing the section in brackets only those having the section bracket outside the {{ic|ic tag}} would be workable. However, we generally want to give the man reference prominence and for that a "see {{ic|man passwd}} for options" is more prominent than a "see passwd(1) for options". That said, I'd personally like the non-ic version because it is a better textflow in my view. Plus the prominence the ic-tag gives is watered down the more it is used for peripheral commands. <br />
:::For the reason you give regarding the author (the editor deciding whether {{ic|man 5 passwd}} or {{ic|man 1 passwd}} is referenced) it seems safe to leave it optional like Kynikos suggests. <br />
:::To add another thought: In special cases it may even be helpful to reference it externally, e.g. like [http://linux.die.net/man/5/passwd passwd's manpage], particularly when it can be assumed the user has no access to it yet on the system itself. For example: we frequently have man references in the article preface, but referencing a package's man page at that early point (before the installation section) is not particularly reader friendly. The problem with external links is of course consistency, i.e. there are too many outdated external references. But most editors are well aware of that, I'd say. <br />
:::So, with the exception of special cases, I am +1 to Kynikos' suggestion if a rule is made, but like to add that I don't feel a need for it to be standardised. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:44, 29 June 2014 (UTC)<br />
<br />
::::Good point Indigo, we can't assume the manpage's package is installed. I'd say we can allow two versions of references to manpages:<br />
::::* If the package is probably not installed, use "see ''pacman'''s [https://www.archlinux.org/pacman/pacman.8.html manual] for details" with the recommendation to prefer linking to the official web representation of the manpage, if available.<br />
::::* If the package is probably installed, use "see {{ic|man 8 pacman}} for details", with the possibility to omit the section number when not ambiguous.<br />
::::* If the manpage is linked in a See also section, use the normal See also style instead (discussed in [[#Manpages in "See also" sections]]).<br />
::::Do you like it? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:19, 30 June 2014 (UTC)<br />
<br />
:::::Oh, fine with me. Thanks for working it out. I particularly like the recommendation towards referencing official package's web manpages too; very beneficial for content overall & software rolling forward. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:14, 30 June 2014 (UTC)<br />
<br />
::::::[https://wiki.archlinux.org/index.php?title=Mount&diff=330649&oldid=330646 This] is one of the reasons why external links for man pages can be harmful - some distributions may provide patched packages including patched man pages. As Arch provides mostly vanilla packages, the link should lead to upstream's page, which should be the most up to date version (also third-party sites may become outdated after some time). Perhaps this should be mentioned as well. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:59, 16 August 2014 (UTC)<br />
<br />
== Lists, colons, indentation ==<br />
<br />
As a continuation of [https://wiki.archlinux.org/index.php?title=Help_talk:Style&oldid=316593#Block_quotations Block quotations], let's clarify our position to multi-line blocks inside lists and indentation (definition lists without definition terms). I have slightly mentioned this in the previous discussion, and I'd like to finish it here.<br />
<br />
The markup lists are designed to be simple, and apparently are unsuitable for more complex lists, e.g. with multi-line blocks inside. [[wikipedia:Wikipedia:Manual_of_Style/Lists#Bulleted_and_numbered_lists|Wikipedia says]]: "Do not use lists if a passage is read easily as plain paragraphs." I think that most of the "incorrectness" on Arch wiki comes from disobeying this quote. We should probably recommend using the lists only in simple cases, one or two paragraphs in each item at most (use &lt;br> tags to separate them).<br />
<br />
Other common case, unfortunately falling into the non-simple category regarding markup, is that a [[template:note|note]] or [[template:tip|tip]] is presented inside a list. The "common" syntax has been<br />
{{bc|<nowiki><br />
* some text<br />
: {{Note|text to note}}<br />
</nowiki>}}<br />
but I've recently seen a number of edits changing it to<br />
{{bc|<nowiki>* some text {{Note|text to note}}</nowiki>}}<br />
which is something I don't like, because even though the latter renders correct HTML, it makes the wikitext unreadable. As much as we don't like it, definition lists without definition terms are a ''feature'', and the [[mw:Help:Lists|MediaWiki's manual]] is full of such tricks. To achieve a fully correct HTML output only with markup syntax, we would need to fix the parser/renderer anyway, so I think we should focus more on wikitext readability.<br />
<br />
The only way to achieve correct HTML, is to use HTML tags in wikitext, which brings me to the next problem: [https://wiki.archlinux.org/index.php?title=QEMU&diff=next&oldid=321689]. The edit clearly breaks the (future) rule "Do not use lists if a passage is read easily as plain paragraphs.", so the problem is reduced to usage of manual numbering - is it acceptable or do we tolerate HTML tags in such cases?<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:11, 29 June 2014 (UTC)<br />
<br />
:I agree, look at [https://wiki.archlinux.org/index.php?title=Compiz_%28Espa%C3%B1ol%29&oldid=273960 this page broken by a "Translateme" template inside a list]. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 08:30, 29 June 2014 (UTC)<br />
<br />
::I've used the {{ic|<nowiki>* some text {{Note|text to note}}</nowiki>}} trick several times myself, but after reading Lahwaacz's reasoning I won't anymore <small><small>(when I'll remember)</small></small>, as I agree completely: we should aim for the ''cleanest'' source text that results in the ''wanted'' appearance of the page. If the generated HTML is not correct it's indeed a problem of MediaWiki, we shouldn't try to work around it.<br />
::Yes, we should encourage preferring paragraphs or even subsections to lists with long/complex items. About ordered lists, manual numbering looks quite ugly to me, and I feel the same about mixing HTML and wiki markup: I think most (hopefully all) of the cases where it would be needed are better solved in some other way. For example in the QEMU case reported above, the items of that list don't need to be numbered, bullets or subsections should be used. Another notable example is [[Arch_packaging_standards#Submitting_packages_to_the_AUR]], where bullet points would be more appropriate.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:49, 30 June 2014 (UTC)<br />
<br />
:Maybe we can create a template for items? I mean something like this:<br />
:{{bc|<nowiki>* First item<br />
* Second item<br />
* {{Template_name|<br />
Third item<br />
<br />
{{Note|bla-bla}}<br />
<br />
Bla-bla-bla<br />
}}<br />
*Fourth item<br />
</nowiki>}}<br />
:And there will be a good readability of wikitext as well as correct indentations<br />
:-- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 07:47, 4 July 2014 (UTC)<br />
<br />
::This still seems too complicated to me. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:15, 5 July 2014 (UTC)<br />
<br />
::I don't think such template is possible, the blank lines would still break the list (test it for [[Template:bc]] without &lt;nowiki> tags). All the templates for lists on Wikipedia work the other way, template arguments are turned into list items. See for example [[wikipedia:Template:Ordered list]], but it relies on [[mw:Extension:Scribunto|Lua scripting]], which is not available on Arch wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:42, 5 July 2014 (UTC)<br />
<br />
== See also links ==<br />
<br />
This is a low priority discussion, more of a reminder, however I'd like to recommend a unified style for external links in See also sections, because at the moment the various articles are inconsistent about that. These are some options:<br />
<br />
* [https://www.archlinux.org/ Arch Linux home page]<br />
* Arch Linux home page: https://www.archlinux.org/<br />
* Arch Linux home page — https://www.archlinux.org/<br />
* https://www.archlinux.org/ — Arch Linux home page<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:36, 1 July 2014 (UTC)<br />
<br />
:I vote for the first style. It's compact and IIRC already more popular than the other styles. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:00, 1 July 2014 (UTC)<br />
<br />
::Agreed with axper, +1 to the first style. --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:28, 1 July 2014 (UTC)<br />
<br />
:::I like the first style too. Also, I think this is how the Wikipedia does it. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 20:35, 1 July 2014 (UTC)<br />
<br />
::::I'd prefer the first style too, but I forgot that links in See also section can be accompanied by descriptions, these are some examples of how the style can vary: [[Core utilities#See also]], [[Secure Shell#See also]], [[Systemd#See also]], [[KDE#See also]] (funny), [[Xfce#See also]], [[List of applications#See also]]. I haven't made up my mind yet. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:48, 5 July 2014 (UTC)<br />
<br />
::::Meahwhile I've run into a non-standard section in [[Cursor Themes]] and I've changed it [https://wiki.archlinux.org/index.php?title=Cursor_Themes&diff=323541&oldid=323304 like this]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:01, 6 July 2014 (UTC)<br />
<br />
:::::+1 for the first style. Yet the examples show how useful a description can be, I vote for making it optional. Having an optional description behind the link looks much neater as well imo, rather than trying to use the link title to transport it in those cases. <br />
:::::Focussing on the links in [[Systemd#See also]]: some are indeed a little dated (already), but it would be a pity to loose them. I was wondering for a moment whether it would make sense to foster grouping them, e.g. <br />
::::::* systemd tips and tricks: <br />
::::::** [http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions systemd FAQ]<br />
::::::** [http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks systemd tips and tricks]<br />
::::::** [http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]<br />
::::::* systemd project information: <br />
::::::** [http://0pointer.de/blog/projects/systemd.html Lennart's blog story] - on the motivation to create systemd <br />
::::::** ...<br />
::::::** [http://0pointer.de/blog/projects/systemd-update-3.html systemd status update 3] — (April 2012)<br />
:::::But then again there are few cases with that many links and the description can be useful/enough to transport that information too. Some sort of grouping happens automatically by editors keeping relevant links together and ordering most relevant (e.g. project home pages) first. <br />
:::::In my view the whole could be clarified by just appending some examples to [[Help:Style#.22See_also.22_sections]] ala: <br />
::::::Examples: <br />
::::::* [https://www.archlinux.org/ Arch Linux home page]<br />
::::::* [http://www.x.org/releases/current/doc/man/man3/Xcursor.3.xhtml man Xcursor] — for more information about cursors in X (supported directories, formats, compatibility, etc.).<br />
::::::* [http://0pointer.de/blog/projects/systemd-update-3.html systemd status update 3] — (April 2012)<br />
:::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:28, 11 August 2014 (UTC)<br />
<br />
== Preferred subpage method ==<br />
<br />
Options:<br />
<br />
* Page/subpage (examples: [[Perl Background Rotation/Tips]], [[List of applications/Utilities]])<br />
* Page - subpage (ex: [[Btrfs - Tips and tricks]]<br />
* Page subpage (ex: [[GNOME tips]], [[pacman tips]])<br />
* No subpages (using sections instead)<br />
<br />
See also: [[#Slashes_in_titles]] --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:16, 2 July 2014 (UTC)<br />
<br />
:I think, current method (number one) is good. The third one is bad (for example, it's very bad for ''List of applications Utilities''). You can add another method with colon symbol: ''Page:subpage''. But I'm ok with the first one -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 07:56, 4 July 2014 (UTC)<br />
<br />
::As [[mw:Help:Subpages|subpages]] are a feature of MediaWiki, the ''only'' way to have a full subpage experience is the first option. Unfortunately, it is currently disabled in the ''Main:'' namespace on Arch wiki (see [[#Slashes in titles]]). Until it is enabled, all options have equal weight, but using anything different than slashes does not make sense if we want to eventually switch to them. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:20, 4 July 2014 (UTC)<br />
<br />
:::As Lahwaacz says, using the slash form is the way to go for forward compatibility, do we want to write a rule and already start changing the existing non-compliant titles (e.g. [[pacman tips]])? The problem is that without the little navigation links under the title, it's not immediate to understand the meaning of the slash, especially for short titles, which at the moment look neater with a simple space. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:59, 5 July 2014 (UTC)<br />
<br />
::::My vote goes for option #4 (using sections like Wikipedia):<br />
::::# Doesn't to pollute the "Related articles" column with number_of_subpages<sup>2</sup> lines (or equivalent) with added complexity of maintaining all that<br />
::::# Doesn't pollute the category pages<br />
::::# It's easier to find information (i.e. {{ic|Ctrl+f}} or {{ic|/}} or by looking at TOC)<br />
::::# No confusion caused by non-existent separator character<br />
::::# Is just simple. Remember KISS? :)<br />
::::[[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:08, 8 July 2014 (UTC)<br />
<br />
:::::OK, let's compare us to Wikipedia (see [[wikipedia:Wikipedia:Subpages]] for reference). Basically, it forbids using subpages in the ''Main:'' namespace. The history section states, that subpages were once used to create hierarchies of articles, but then it was superseded by categories and disambiguations. On Arch wiki, the hierarchy of categories was designed as a ''tree'' (although in practice with some "converging branches", see [https://wiki.archlinux.org/index.php?title=Help_talk:Style&oldid=324150#Category_pages_-_tree_or_otherwise.3F #Category pages - tree or otherwise?]) and we don't use disambiguations at all. Unlike Wikipedia, so far this system works quite well on Arch wiki, which I think is mainly due to the type of content, amount of content and greater devotion and attention to detail of the [[ArchWiki:Maintenance Team|Maintenance Team]] :)<br />
:::::Sometimes an article is too long to be kept on just one page, and the easiest solution is to split some ''section'' into a separate article, which will effectively create a ''subpage''. I don't really see how this could be avoided without completely rewriting it, disambiguations or categories won't help here.<br />
:::::But I could agree that the usage of subpages should be regulated, for example [[PulseAudio/Troubleshooting]] would be good, while [[Kernels/Compilation/Traditional]] would be wrong (see the Wikipedia case). I don't know yet about [[Color Bash Prompt]] and something like [[Bash/Color prompt]].<br />
:::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:00, 9 July 2014 (UTC)<br />
<br />
::::::Well, solution #4 would be ideal, but in practice I think we can't really help splitting articles, both for length issues and because it's hard to understand when to stop merging articles back to their "parents". Take for example [[dm-crypt]]: it has several quite long subpages, would an article that merges all of them be clearer to read? I wouldn't see it as an improvement. And then why not merge [[dm-crypt]] and the others back to [[Disk encryption]]?<br />
::::::A subpage system is much more manageable, especially from the point of view of the maintainers, rather than the readers, so we just have to stick with it and make it as efficient and organized as possible.<br />
::::::@Lahwaacz How would you rename [[Kernels/Compilation/Traditional]]? [[Kernels/Compilation]] is the only child of [[Kernels]] (and currently only a redirect), so probably all those [https://wiki.archlinux.org/index.php?title=Special%3APrefixIndex&prefix=Kernels%2F&namespace=0 subpages] could be moved to [[Kernels/Traditional compilation]] and so on. Maybe we could limit the depth of subpages to just 1 in general?<br />
::::::About [[Color Bash Prompt]], I think its natural subpage version would be more [[Bash/Prompt color]], or, considering the actual content of the article, [[Bash/Prompt customization]] (I think we're using the AE spelling everywhere, but that's something else that's not regulated yet), [[Bash/Prompt style]] or similar.<br />
::::::-- 09:57, 10 July 2014 (UTC)<br />
<br />
:::::::Yes, [[Kernels/Traditional compilation]] looks good. About [[Color Bash Prompt]], I think that "color" is either a verb (as in "colorize") or an adjective, so I used it the same. But your alternatives are better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:21, 10 July 2014 (UTC)<br />
<br />
::::::::Thanks, what about limiting the depth of subpages to 1? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:13, 12 July 2014 (UTC)<br />
<br />
:::::::::I wouldn't mind more levels, provided that the first/previous level is wide enough. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:49, 12 July 2014 (UTC)<br />
<br />
== OK to put category pages in related articles list? ==<br />
<br />
Recently I made some edits which replaced links to multiple articles with a single link to a category page. That category page contains all those articles.<br />
* [[:Category:Hypervisors]]<br />
* [[:Category:Network managers]]<br />
<br />
Are people OK with this? If so, maybe edit [[Help:Style#Related_articles_box]] here to instead say:<br />
<br />
{{Box||<br />
* Provides a simple list of related internal pages.<br />
* Optionally included right below categories (or interlanguage links, or Article status templates, if present).<br />
* It can only be made of [[Template:Related articles start]], [[Template:Related]] and [[Template:Related articles end]]. See also the guidelines in those pages.<br />
* Non-English pages can make use of [[Template:Related2]] for translating the anchor text.<br />
* Use the [[#"See also" sections|"See also" section]] for a more complete and detailed list that also includes link descriptions and interwiki or external links.<br />
}}<br />
<br />
(change the word "article" to "page")<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:33, 10 July 2014 (UTC)<br />
<br />
:My first thought when reading this was "when the article is not included in the given category and it is still relevant, it should be included, otherwise not". On second thought, if the category is relevant enough, the article can be simple put into that category. The big problem is that related articles are at the top and related categories at the bottom.<br />
:We can either 1) leave pages at the top and categories at the bottom, 2) include every category into the 'Related articles' box at the top, 3) move the list of categories to the top (how?), 4) move the 'Related articles' box to the bottom (merge into 'See also' again).<br />
:Yep, so far I don't like either one of them for some reason or another...<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:25, 10 July 2014 (UTC)<br />
<br />
::About axper's proposed amendment, I agree, if a group of articles don't have a generic overview (e.g. unlike [[window managers]]), then linking to the category that groups them can be useful, if the edited article is not part of such category. Of course if the article itself is part of the category, there's the problem of duplicating the category link in the source text. This reminds me of an old idea of mine that I explained in [https://wiki.archlinux.org/index.php?title=Help_talk:Style/Article_summary_templates&oldid=287617#A_crazy_idea_.28about_Summary_templates.2C_Overview_templates_and_categories.29]: translated to the "modern" wiki, it could mean replacing the normal categorization system with a [[Template:Category]] to be added to the Related articles box, when present, so that the article gets categorized under some categories, but their links are also shown somehow in the floated box. For example:<br />
{{hc|Current system|<nowiki><br />
[[Category:Foo]]<br />
[[Category:Bar]]<br />
{{Related articles start}}<br />
{{Related|link}}<br />
{{Related articles end}}<br />
<br />
Body<br />
</nowiki>}}<br />
<br />
{{hc|New system|<nowiki><br />
{{Related articles start}}<br />
{{Category|Foo}}<br />
{{Category|Bar}}<br />
{{Related|link}}<br />
{{Related articles end}}<br />
<br />
Body<br />
</nowiki>}}<br />
<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:33, 12 July 2014 (UTC)<br />
<br />
:::The problem is that it involves more writing when there are no related articles (it is necessary to add <nowiki>{{Related articles start}}</nowiki> and <nowiki>{{Related articles end}}</nowiki> around the cats). Or would we use the current system for such pages? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:40, 12 July 2014 (UTC)<br />
<br />
::::I was just brainstorming, I'm not sure, maybe we could start using the RA box on every article? [[Wiki Monkey]] should have all the libraries needed to automate the migration, both for articles with an RA box and for those without, so the "extra writing" disadvantage wouldn't really apply. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:24, 13 July 2014 (UTC)<br />
<br />
== Convention on added/removed text in Hc Templates ==<br />
<br />
I just [https://wiki.archlinux.org/index.php?title=Nautilus&diff=prev&oldid=324433 used] the following way to clarify removed/added text in [[Nautilus#Use delete key to move to trash in Nautilus 3.6 and above]]:<br />
<br />
{{hc|~/.config/nautilus/accels|<br />
''<s>; (gtk_accel_path "<Actions>/DirViewActions/Trash" "<Primary>Delete")</s>''<br />
(gtk_accel_path "<Actions>/DirViewActions/Trash" "Delete")<br />
}}<br />
<br />
Is there already a policy on this? --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 23:29, 10 July 2014 (UTC)<br />
<br />
:Nope, there's no policy on that (yet?). Your version is certainly an improvement, compared to the previous {{ic|-+}} system, although in my opinion there's no need to add italic to the stricken line (keep it simple). What I think I've seen around more often, though, is a more verbose:<br />
<br />
::In {{ic|~/.config/nautilus/accels}}, replace:<br />
::{{bc|; (gtk_accel_path "<Actions>/DirViewActions/Trash" "<Primary>Delete")}}<br />
::with:<br />
::{{bc|(gtk_accel_path "<Actions>/DirViewActions/Trash" "Delete")}}<br />
<br />
:Your version has the advantage of using [[Template:hc]], thus making it ''visually'' clearer that those lines are two versions of the same line, and belong to the same file. The "verbose" version has the advantage of giving clearer ''written'' instructions about what has to be done.<br />
:Replacing lines doesn't seem to be very frequent in articles, maybe standardizing this would be too much. If we decided to use the "stricken" version, it would probably be worth adding a note in [[Help:Reading#Append, create, edit and source]].<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:30, 11 July 2014 (UTC)<br />
<br />
== Links to redirects ==<br />
<br />
I'd like to recommend avoiding links like {{ic|<nowiki>[[Xorg#Composite|AIGLX]]</nowiki>}} or {{ic|<nowiki>[[daemons|daemon]]</nowiki>}} and promote linking to redirects, e.g. {{ic|<nowiki>[[AIGLX]]</nowiki>}} or {{ic|<nowiki>[[daemon]]</nowiki>}}: this would have the advantage of:<br />
<br />
# making the source text simpler and easier to read<br />
# keeping track of the particular "reason" why a link is made, also grouping the various links by "reason" in WhatLinksHere pages<br />
# allowing quickly updating link fragments in case of section renames<br />
<br />
We may even encourage to create redirects like those when the alternative text could be used somewhere else.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:09, 12 July 2014 (UTC)<br />
<br />
:Exactly my thoughts, we've gotten too far in the "update link(s) (avoid redirect)" series of edits, which apparently set a bad example for others. Redirects are a feature and as such should not be avoided, except for the following cases (which I consider confusing):<br />
:# the titles differ only in capitalization<br />
:# the link is given in the 'Related articles' floating box<br />
:# two links to the same target are given next to each other, one of them goes over redirect<br />
:Also when a phrase {{ic|<nowiki>See [[Some page]] for details.</nowiki>}} is used, it should be a direct link, but this is not very confusing and likely depends on context, sometimes redirects might be desired even in this case.<br />
:There are also some tricks to save writing the anchor text in some cases, see for example [[Help:Editing#Pipe trick]]. Then there is the following syntax: {{ic|<nowiki>[[window manager]]s</nowiki>}}, which will result in [[window manager]]s, but this can be solved also with a redirect. (off-topic: does [[Wiki Monkey]] support this?)<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:21, 12 July 2014 (UTC)<br />
<br />
::I agree with the exceptions. About {{ic|<nowiki>See [[Some page]] for details.</nowiki>}}, I'd still consider my points 2) and 3), and maybe at least don't explicitly list the case among the exceptions (we'll have to write this rule more as a recommendation than an obligation anyway, so the editors will be able to decide case by case). We could also recommend the pipe or the suffix trick over redirects when it's possible to use them. (OT: nope, [https://github.com/kynikos/wiki-monkey/issues/186 #186] [https://github.com/kynikos/wiki-monkey/issues/188 #188]) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:21, 13 July 2014 (UTC)<br />
<br />
== Titles: singular or plural? ==<br />
<br />
Currently we have [[daemons]], [[List of applications]], [[:Category:Proxy servers]]... but also [[window manager]], [[display manager]], [[:Category:Mail Server]]... I'm for enforcing the plural version in all cases. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:26, 13 July 2014 (UTC)<br />
<br />
:I agree, plurals sound better, it's also how Wikipedia does it:<br />
:* [[Wikipedia:Wikipedia:Naming_conventions_(plurals)#Exceptions]]<br />
:* [[Wikipedia:Wikipedia:Category_names#General_conventions]]<br />
:[[User:Axper|axper]] ([[User talk:Axper|talk]]) 07:35, 13 July 2014 (UTC)<br />
<br />
== Questionable edits ==<br />
<br />
There are several kinds of questionable edits made almost regularly to the wiki. They are '''not''' breaking any rules (yet?), I just find them useless, counter-productive, or even annoying. I'd like to discuss them to see how others feel. Of course feel free to add a section of your own. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
=== Underscores vs. slashes in kernel module names ===<br />
<br />
Example: [https://wiki.archlinux.org/index.php?title=USB_storage_devices&diff=next&oldid=328933] vs. [https://wiki.archlinux.org/index.php?title=Advanced_Linux_Sound_Architecture&diff=311976&oldid=310951]<br />
<br />
From {{ic|modprobe(8)}}: ''"there is no difference between _ and - in module names (automatic underscore conversion is performed)"''. Not only the naming is inconsistent across the wiki, this could lead to edit wars.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:Let's just pick one style and go with it. I vote for undescores, since that's how {{ic|lsmod}} prints them, consistency would be nice.<br />
:I wouldn't consider these 2 edits questionable, rather it's lack of [[Help:Style]] rules about this particular subject.<br />
:[[User:Axper|axper]] ([[User talk:Axper|talk]]) 06:04, 10 August 2014 (UTC)<br />
<br />
::+1 for regulating this with underscores as per axper's lsmod argument. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
=== <s>Versioned links</s> ===<br />
<br />
Examples: [https://wiki.archlinux.org/index.php?title=USB_Flash_Installation_Media&diff=prev&oldid=323158], [https://wiki.archlinux.org/index.php?title=USB_Flash_Installation_Media&diff=prev&oldid=328011]<br />
<br />
I don't mind anybody updating the values, I just cannot understand why would someone update ''all'' of them regularly. It should be expected that these values will be outdated soon, the wording around them should make this clear.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:Well, this doesn't constitute a problem, right? If somebody updates them often I guess it's ok, it's not that we can write a rule like "don't update stuff too often" :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::I'm getting too lazy, and lazy people should not infect their surroundings, so I'll just close this... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:04, 16 August 2014 (UTC)<br />
<br />
=== Nice tables ===<br />
<br />
Examples: [https://wiki.archlinux.org/index.php?title=Xorg&diff=327837&oldid=327835], [https://wiki.archlinux.org/index.php?title=Repo-ck&diff=329471&oldid=329461]<br />
<br />
I think that we can afford to have ''nice'', colourful tables. The syntax for wikitables is not very well readable anyway, so a little of HTML will not hurt.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:Still, the HTML syntax is more complex than wiki-tables (and currently discouraged). You'd have to consider where "nice" fits in, compared to simplify editing content, where possible.<br />
:On the topic of HTML, I'd like to bring up a far more extreme example, [[Color_Bash_Prompt]], which seems nigh impossible to change in the standard editor ... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:34, 9 August 2014 (UTC)<br />
<br />
::The readability of wiki tables, both from wiki-text and rendered HTML, depends more on the amount of text inside the table, number of columns, (lack of) additional wiki formatting etc. Of course I agree that generally tables should be kept as simple as possible, but colours can improve the readability of HTML without substantial worsening of the wiki-text readability, so I'd say it's worth to use them.<br />
::And anyway, there is actually a wiki syntax available for specifying attributes for each cell, row, or table as a whole: [[wikipedia:Help:Table#Color.3B_scope_of_parameters]].<br />
::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:28, 9 August 2014 (UTC)<br />
<br />
:::On this topic, I'm for sticking to the no-HTML rule, but I'm perfectly fine with the native way of using CSS as reminded by Lahwaacz.<br />
:::Then there would be the template way of solving this problem, see [[ArchWiki talk:Reports#New templates]].<br />
:::About [[Color Bash Prompt]], that's an exception because HTML is the only way of presenting examples.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::::[[Wikipedia:Template:Table_cell_templates]] would do the trick. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:35, 19 August 2014 (UTC)<br />
<br />
=== Alphabetical order ===<br />
<br />
Example: [https://wiki.archlinux.org/index.php?title=Xorg&diff=prev&oldid=327850]<br />
<br />
Unless in lists (such as [[List of applications]]), alphabetical sorting of sections or other items is useless, I'd even say wrong. Alphabetical sorting is good for finding things, but we have full-text searching nowadays. Even ''chronological'' sorting (assuming that new sections are added to the bottom) is more useful for ''Troubleshooting'' sections.<br />
<br />
Also, have you ever read a book with chapters sorted alphabetically?<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:I think as long as the sorted sections are ''equivalent'' (as in, alphabetical order does not break logical order), you could probably make an argument for both. Should a rule for chronological sorting be found useful, however, I wouldn't object to it. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:41, 9 August 2014 (UTC)<br />
<br />
::Yes, I'd expect a section about a ''new'' bug I am looking a solution for to be at the end of the article. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 06:20, 10 August 2014 (UTC)<br />
<br />
:::First, the example edit should have been split (i.e. one section moved at a time).<br />
:::About the issue, I don't think that alphabetical order can make sense in Troubleshooting or Tips and tricks sections, since the first word of the headings is often incomparable (can be an article, a noun, etc.); chronological order would be better, for example a rule could recommend adding sections at the bottom (or top) of such section groups, unless some similar ones already exist, and in that case I guess keeping similar sections next to each other would be preferable.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::::+1, Lahwaacz is right. And one example for keeping similar sections next to each other: [[GNOME#Extensions]] -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 12:21, 20 August 2014 (UTC)<br />
<br />
=== Concision ===<br />
<br />
(without example)<br />
<br />
Several times recently I was ''amazed'' as to how can be a concise article made even more concise. I think that we need more ''precision over concision''. I think that the ''good'' wiki pages are usually verbose, as the topic is usually too complex to be described concisely. As tempting as it may be, having an expert making it more concise is not helpful for the majority of others.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:I think there's a difference between concision in ''style'' and concision in ''content''. Former is a matter of correct writing (convey information that helps understanding, not make it difficult); see [https://wiki.archlinux.org/index.php?title=Skype&diff=prev&oldid=328283] for a simple example. Latter should be avoided, and flagged (for example [https://wiki.archlinux.org/index.php?title=PPTP_Server&curid=9499&diff=329500&oldid=329283]) where appropriate. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:24, 9 August 2014 (UTC)<br />
<br />
::We can indeed put some recommendation like that in the guide, but this is something that the wiki staff will always have to keep an eye on, because experience is the only way to judge, case by case, what's too verbose and what's too concise. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::Thanks for this hint. I've never recognized concision as a [[wikipedia:Concision|term]] and always associated it only with removing of content, either large parts or nuances that might have been intended by the previous editor. Although the [[Help:Style#Language register|language]] should be concise, let's not take it too far. And especially watch out for the nuances. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:08, 10 August 2014 (UTC)<br />
<br />
== Hidden text ==<br />
<br />
:''moved from [[Talk:USB Flash Installation Media]] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:20, 15 August 2014 (UTC)<br />
<br />
Edition 330359, Using manual formatting in Windows.<br />
<br />
Regarding the following edition:<br />
https://wiki.archlinux.org/index.php?title=USB_Flash_Installation_Media&diff=330359&oldid=330302<br />
<br />
In the hidden text ("unhidden" by the edition #330359), I am not disputing the accuracy of the section.<br />
I am purposely leaving a hidden note for future editors.<br />
<br />
Someone could think that the referenced Note is not %100 technically accurate, and he would be correct.<br />
But the technical accuracy needs to be balanced with the real purpose of the wiki article: helping users with their task.<br />
<br />
In this particular case, a deeper technical explanation would make the referenced Note more accurate, but it would unnecessarily over-complicate the text for common users.<br />
<br />
In other words, by adding the hidden note I am "hinting" to potential editors to keep the section "as clear as necessary" for common readers/users so they would be able to perform the task, but without adding or correcting technical details that in practice would not further the real goal of typical readers/users. "As detailed as necessary, but not more than that".<br />
<br />
Therefore, I am inclined to undo the edition #330359 made by [[User:Lahwaacz]].<br />
Would you agree? {{Unsigned|18:51, 15 August 2014|Ady}}<br />
<br />
:HTML comments are neither mentioned in [[Help:Style]], [[Help:Editing]], or similar documents, and in general use of HTML is discouraged. See [[Help:Style#HTML_tags]].<br />
:And to be frank, a distinction between "readers" and "editors" is counterproductive. If a note is deemed not accurate, it should be removed, or if there's uncertainty, it should be mentioned on the talk page. Closing, feel free to re-open if there's doubts. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:37, 15 August 2014 (UTC)<br />
<br />
::Re-opening. IMHO, in certain cases there are differences between "readers" and "editors". The (previously hidden) text is useful for potential editors (those who (should) know enough about the subject), but it would be counterproductive for common users, who are just trying to follow practical steps.<br />
<br />
::I didn't use the hidden text formatting because of style, but because this is precisely the way to help editors without interfering with the normal flow of the text for readers.<br />
<br />
::The usage of <nowiki><!--Comment--></nowiki> for MediaWiki is explained, among other help pages, in http://en.wikipedia.org/wiki/Help:Hidden_text .<br />
::In the same page, http://en.wikipedia.org/wiki/Help:Hidden_text#Appropriate_uses_for_hidden_text :<br />
<br />
:::''Providing information to assist other editors...''<br />
<br />
::since the text would be counterproductive for readers, but useful for editors, I used the standard formatting for any MediaWiki.<br />
<br />
::Certainly the "accuracy" notice being displayed for common readers is counterproductive.<br />
<br />
::If I had to chose between:<br />
::* showing the "accuracy" notice to all readers; or<br />
::* not having the text at all;<br />
::and without the possibility to have the text as "hidden" to help editors, I would choose for not having the text at all, leaving the referenced Note alone.<br />
<br />
::Evidently I am of the opinion that the hidden text is the adequate method for its purpose.<br />
<br />
::Do you still disagree with leaving the text with MediaWiki's hidden formatting? [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 19:08, 15 August 2014 (UTC)<br />
<br />
:::Yes. ArchWiki "readers" are "editors" by definition. From [[The_Arch_Way]]:<br />
<br />
::::Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system. (...)<br />
<br />
::::This user-centric design necessarily implies a certain "do-it-yourself" approach to using the Arch distribution. Rather than pursuing assistance or requesting a new feature to be implemented by developers, Arch Linux users '''have a tendency to solve problems themselves and generously share the results with the community and development team – a "do first, then ask" philosophy.'''<br />
<br />
:::Either way, I see no argument to ''not'' use Talk pages for these purposes. A talk page doesn't interrupt the "normal flow" of reading, yet remains fully transparent. (PS: moving this discussion to [[Help talk:Style]]) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:19, 15 August 2014 (UTC)<br />
<br />
:::: IMHO the Talk pages are for discussions. The hidden formatting is for direct immediate help for a potential future relevant editor (who can clearly and immediately read the hidden text before saving his next related edition). Both methods are valid, because their respective goals and uses are different.<br />
<br />
:::: Even in The Arch Way, no one can know every single technical detail behind every single step. A reader follows the practical steps provided in an article. While the practical steps could be generally understood and successfully followed, there might be deeper technical reasons that are not necessarily understood or known by every reader/user. This is such a case.<br />
<br />
:::: In the particular section of the particular article we are discussing, I happen to know why there is a need for the referenced Note (as opposed to just skip it entirely). The referenced Note is adequate for users following the practical steps, but from a deeper technical level this referenced Note is only "%95" accurate.<br />
<br />
:::: For such "%5 inaccuracy" (which would require a lot of explanations in the wiki article), I'm not going to get into more discussions, specially considering that the practical steps for any user following the article are correct and adequate anyway.<br />
<br />
:::: As I mentioned before, if I had to choose between only two alternatives: either showing the "Accuracy" notice for everyone, or not showing the (previously hidden) text at all (not even for editors), I would choose the latter in this particular case. The reason is clear: the practical steps to be followed by users _are_ accurate.<br />
<br />
:::: The potential discussion about the usefulness of hidden text (aka comments) for editors in very specific cases is for mods, admins and alike. Regarding the particular edition that triggered this discussion about hidden text, I'll edit the wiki article so to delete the text; it will not be hidden, nor shown as "accuracy" notice. Thank you. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 21:27, 15 August 2014 (UTC)<br />
<br />
:::::The problem here is that you don't ''own'' that note, i.e. you have no special rights to indicate whether and how to modify it to other users. The same goes for everybody with every bit of content in every article. We could let users fill the pages with notes telling others how they'd like them to edit their original work, but the result would end up being a total mess, as can be imagined. IMO the only right you have is to discuss future edits (or intentions to edit) with the users who will show interest, and the only wiki way to do it is to add this article in your ''watchlist'' and watch it against counterproductive edits for as long as you are interested.<br />
:::::But where exactly is that note inaccurate? Because usually when you feel some deeper explanations are out of place in some article it's because that article's topic is quite different, so the details should belong somewhere else: is it something regarding [[syslinux]]? Because we have an entire article for it, maybe you could add what's needed there and simply link there from the note?<br />
:::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:59, 16 August 2014 (UTC)<br />
<br />
::::::We keep derailing further from the initial goal. No one claimed, suggested nor thought about owning anything. The purpose of leaving a comment for editors is to help them (editors) without "hurting" the normal flow for readers. MediaWiki uses this formatting as standard, precisely for the purpose I used it for (and I used it for what MediaWiki already considers as a valid, acceptable purpose for leaving hidden text).<br />
<br />
::::::Most frequently an editor won't read a Talk page for an edition where there is no "discussion" needed, specially in long pages with several sections (like it was in this case). The purpose of the "hidden" comment was to effectively "hint and help", not to impose or own anything.<br />
<br />
::::::In this particular case, some potential future editor might think "hmm, the technical background mentioned here is not %100 accurate, let's add several paragraphs of explanations". My "hint" attempted to say "please consider that, although the technical background is not %100 accurate here, the practical steps are clear and effective, there is no real need for additional background in this particular article, and the information already displayed is really needed". In other words, ''balance'' accuracy with clarity and effectiveness.<br />
<br />
::::::If a potential editor would want to ignore (and/or delete) the hint and add more information that is really not needed by the users to be able to follow the steps, then no one can stop him.<br />
<br />
::::::The edition from [[User:Lahwaacz]] said "''don't use HTML comments, they are not rendered''", and he added an "Accuracy" notice instead of the hidden text. Well, I purposely wanted the information to be not rendered for common readers, and my (previously) hidden text read "...it is accurate-enough so to be able to perform the task", which means the _opposite_ of showing the "Accuracy" notice. BTW, please note that [[Help:Style]] was not even mentioned in the reason for his edition.<br />
<br />
::::::As mentioned in http://en.wikipedia.org/wiki/Help:Hidden_text#Appropriate_uses_for_hidden_text , there are _appropriate_ uses for hidden text, and this was one of them.<br />
<br />
::::::Since the discussion has been moved from its original article, the focus has changed, from the technical details regarding "USB Flash Installation Media" and "Syslinux" steps, to "whether in this particular case the usage of 'comments' (aka hidden text) is adequate". In this particular case, I still consider that adding hidden text was appropriate, so to benefit both, readers and editors.<br />
<br />
::::::I have already eliminated the original source that triggered this discussion. I still think that there are valid reasons to use 'comments' in certain cases. Thank you. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 12:47, 16 August 2014 (UTC)<br />
<br />
:::::::There are several assumptions here:<br />
<br />
:::::::1. Editors tend to not read talk pages "where there is no discussion needed" (?)<br />
:::::::2. They particularly don't for "long pages"<br />
:::::::3. Editors always read pages in "Edit" mode<br />
<br />
:::::::I can't speak for others, but personally I have a "reactionary" editing style - I'm a "reader" (regular mode), and when I see something off or want to add something, I enter "Edit" mode. If I'm unsure, I '''collaborate''' edits by mentioning it in the article's talk page, or possibly an editor's talk page (including watchlist, as Kynikos mentioned). I also don't believe point 2 is fair; due to the close/delete policy of ArchWiki, talk pages are most often relevant to the current article and have a good overview. (Admittedly [[Help talk: Style]] is an exception, but that's expected)<br />
<br />
:::::::If you're sure something is ''glaringly'' inaccurate you use [[Template:Accuracy]], or simply fix the article directly (with the time spent to this discussion, it may have been done already...); as Kynikos said, this may include (links to) "outside" content. Otherwise, see the previous paragraph.<br />
<br />
:::::::Personally I'm still unconvinced of adding another method or rule. Re your BTW, not mentioning [[Help:Style]] was most likely an oversight (this is usually mentioned in edit summaries). Anyway, I'm bailing out... I'll see what comments others make. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:28, 16 August 2014 (UTC)<br />
<br />
::::::::@Ady (reopening): first of all I want to make clear that I didn't write the "own[ing]" argument in an accusing way, it was only meant to explain my point of view, I should have added a smiley at the end, I'll do it now :)<br />
::::::::More important, you said we "derail[ed] from the initial goal", but actually I asked you some questions that were very relevant and specific to your edit, and you haven't answered, so I'll paste them here again:<br />
::::::::Where exactly is that note inaccurate? Because usually when you feel some deeper explanations are out of place in some article it's because that article's topic is quite different, so the details should belong somewhere else: is it something regarding [[syslinux]]? Because we have an entire article for it, maybe you could add what's needed there and simply link there from the note?<br />
::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:49, 17 August 2014 (UTC)<br />
<br />
:::::::::@Kynikos, Since the discussion was moved, the focus changed from the more-technical matter to whether using hidden text was/is appropriate (in this particular case). Thus, I thought that perhaps answering those questions here would have been considered off-topic.<br />
<br />
:::::::::The referenced Note says "''The above step installs Syslinux's ldlinux.sys to the VBR of the USB partition, sets the partition as "active/boot" in the MBR partition table and writes the MBR boot code to the 1st 440-byte boot code region of the USB.''". As you can see, this Note is not part of a practical step (and therefore, a slight inaccuracy is likely not going to affect a typical reader following the instructions). Yet, there is a purpose for this Note.<br />
<br />
:::::::::Users kept asking (including to upstream Syslinux) whether they can skip part of the steps, and just copy over ldlinux.sys (for example, to either install or update SYSLINUX in their USB drives). Moreover, some users didn't even ask; they simply (over)wrote this file and they complained that SYSLINUX (and/or Arch) fails to boot. So the Note is there to prevent this type of behavior / confusion / repeated waste of time. This explains why deleting the referenced Note would not be wise.<br />
<br />
:::::::::About the minor inaccuracy... What the SYSLINUX installer does (when performing the specific steps exactly as described in the relevant section of the article) is to:<br />
:::::::::* copy ldlinux.{sys,c32};<br />
:::::::::* patch the VBR so it can point to the correct block in the device (so ldlinux.sys can be found);<br />
:::::::::* set the partition as "active/boot" in the partition table;<br />
:::::::::* write the MBR boot code to the 1st 440-byte boot code region of the USB.<br />
<br />
:::::::::I want to clarify that the above description is only relevant for the specific section we are referring to. The SYSLINUX/EXTLINUX installers perform different tasks according to different cases.<br />
<br />
:::::::::So, there is a minor (technical) background inaccuracy in the Note.<br />
<br />
:::::::::Considering the goal of this Note (as I already described it above) in the context of this particular section of this particular article, and considering that the practical steps provided in the article are not affected by this minor inaccuracy, I asked my self (at the time I performed other editions on the article) whether I should also edit the Note. Would I be actually helping a typical reader that is interested in following the steps? With the objective to balance between accuracy and clarity for the typical reader, I decided not to over-complicate the Note with excessive details that in practical terms only would make the section longer without improving the outcome.<br />
<br />
:::::::::Adding a link to the [[Syslinux]] article would not improve the practical experience / steps for the user in this case. If anyone wants to find more technical information, they don't need yet another link from that same article to the same Syslinux page. In this article, the typical reader is (and/or should better be) likely focused on the practical steps.<br />
<br />
:::::::::Thus, my "hint" was "''This note is not %100 technically accurate, but it is "accurate-enough" so to be able to perform the task.''". For the typical reader trying to follow the practical steps, the procedure is accurate and he will complete the task successfully, so adding an "Accuracy" box would be counterproductive.<br />
<br />
:::::::::Generally speaking, I think there are cases where adding 'comments' (aka hidden text) is adequate, but I am perfectly fine following the guidelines in [[Help:Style]]. Lahwaacz's edition formatted the "hint" as "Accuracy" box, going exactly in the opposite direction of what the hint itself was saying (or at least, against the original intention of the comment). This was not beneficial for users, so I deleted the box.<br />
<br />
:::::::::Slightly long to read (apologies), but I hope this clarifies the matter. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 10:45, 17 August 2014 (UTC)<br />
<br />
::::::::::I see, thanks for explaining, then why not make explicit the reason why the note is there (KISS), like:<br />
::::::::::{{Note|<br />
::::::::::* Make sure to run the above command in full, which installs Syslinux's {{ic|ldlinux.sys}} to the VBR of the USB partition, sets the partition as "active/boot" in the MBR partition table and writes the MBR boot code to the 1st 440-byte boot code region of the USB. Only copying the file, for example in an attempt to update an existing Syslinux installation, will result in an unbootable device.<br />
::::::::::* ...}}<br />
::::::::::This way nobody will see the note as useless and delete it.<br />
::::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:50, 19 August 2014 (UTC)<br />
<br />
:First, sorry for not including the link to [[Help:Style#HTML_tags]] in the edit summary, that was indeed my mistake.<br />
:In addition to the Alad's and Kynikos' replies above, I'd like to remind that ArchWiki is completely different project from Wikipedia and her sister projects, operated by [[wikipedia:Wikimedia Foundation|Wikimedia Foundation]]. ArchWiki has its own sets of rules, that are surely different from the WMF ones. The rule from [[Help:Style#HTML_tags]] regarding HTML comments stands, Alad and Kynikos provided the rationalization. Please respect this rule on ArchWiki.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:34, 16 August 2014 (UTC)<br />
<br />
== Hypertext metaphor interpretation ==<br />
<br />
Regarding [https://wiki.archlinux.org/index.php?title=Talk:VDR&diff=331548&oldid=331546], what is ok to duplicate and what not?<br />
<br />
The relevant rules in [[Help:Style#Hypertext metaphor]] are:<br />
<br />
:* Before writing a specific procedure in an article or describing something in particular, always check if there is already an article that treats that part in detail: in that case, link that article instead of duplicating its content.<br />
:* If the upstream documentation for the subject of your article is well-written and maintained, prefer just writing Arch-specific adaptations and linking to the official documentation for general information.<br />
<br />
''In my view'', the first one refers to internal articles only, so it doesn't apply here. The second should be regulating duplication of external sources. Now, I don't think we can consider https://wiki.debian.org/VDR as the "upstream documentation" for VDR, so I think duplicating the article here could be allowed, as Debian's wiki article (even if written by the same author) can't be considered a more reliable — or better maintained — source than this one. <br />
<br />
I've posted here because I want to discuss the interpretation of those rules in general, and possibly end up improving them to make their meaning clearer.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:57, 21 August 2014 (UTC)<br />
<br />
:You are right that there is no rule to address the issue ''directly'', hence my reply in [[Talk:VDR]] is probably an overstatement. Sometimes I link to [[Help:Style#Hypertext metaphor]] just so that the user gets the general idea.<br />
:To the interpretation of "Hypertext metaphor": IMV, "upstream/official documentation" in the second aforementioned rule ''can be'' "any external resource the editor is currently working with". For some projects, the notion of upstream/official documentation is pretty clear (e.g. [[i3]] with their [http://i3wm.org/docs/userguide.html userguide]), some projects have multiple high-quality "official documentations" (developers' blog posts, manpages, READMEs...), and some projects have none. In the last case it shouldn't matter if the source is hosted on some other distro's wiki or not, they should all have the same priority.<br />
:Regarding maintenance, [[VDR]] is not maintained [https://wiki.archlinux.org/index.php?title=VDR&diff=312049&oldid=239286 since 2012], while [https://wiki.debian.org/VDR Debian's] article has a [https://wiki.debian.org/VDR?action=info stable maintainer] (probably the same person as [[User:Cdwijs]]). This could be a reason both for and against porting the Debian's article here, but maintaining a single article is surely easier than maintaining two.<br />
:It is also questionable if porting an article from MoinMoin (used by Debian's wiki) to MediaWiki syntax can be called a duplication, but I still think it is useless from the reader's point of view.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:07, 21 August 2014 (UTC)<br />
<br />
==<s> Command line text </s>==<br />
<br />
I propose to dis-entangle the templates referenced in first two bullet points of [[Help:Style#Command line text]] as follows: <br />
* When using inline code ([[Template:ic]]), no prompt symbol is to be represented, but any notes about permissions must be added explicitly to the surrounding text.<br />
* When using block code (with [[Template:bc]] or a simple space character in front of each new command line), use {{Ic|$}} as a prompt for regular user commands; use {{Ic|#}} as a prompt for root commands. <br />
<br />
Further to that the bullet points following the note ''could'' be indented one more level to clarify they refer to block code. Having them on the same level as the first two makes it look like they are examples of inline code as well. <br />
<br />
Then there is [[#Ellipses_in_code_examples]] which could be added as a new bullet: <br />
* For code blocks based on a template, e.g. a configuration file, consider focussing the reader to relevant lines and ellipsing ({{ic|...}}) surrounding, non-relevant, code lines. <br />
<br />
in either [[Help:Style#Command line text]] or (better imo) [[Help:Style#Code formatting]]. <br />
--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 08:55, 24 August 2014 (UTC)<br />
<br />
: +1 for all of that -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 10:43, 26 August 2014 (UTC)<br />
<br />
::It's all implemented, thank you Indigo for preparing the text so I could practically just copy and paste it :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:02, 27 August 2014 (UTC)<br />
<br />
==Programming Languages - Introductory Paragraph==<br />
I was looking at the [[Python]] article, and noticed it has a quite verbose description of what Python is, copied from Wikipedia. I would prefer shorter description, which still captures the essentials. In the concrete example, i would pick the first paragraph from [https://docs.python.org/3/tutorial/ python tutorial].<br />
Looking at other articles for Programming Languages, i have noticed an inconsistency. [[D_(programming_language)]] uses the same style (quoting Wikipedia) and [[Java]] also quotes Wikipedia but using a different format. [[Go]], [[Haskell]], [[PHP]] just have a short intro which links to the Language Homepage.This was also the case on the Python article, it was changed there on 2014-07-23.<br />
Would it be a good idea to agree on a common style? Or am i just making a fuss about an unimportant issue?<br />
[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 11:17, 3 September 2014 (UTC)</div>Bwidhttps://wiki.archlinux.org/index.php?title=Help_talk:Style&diff=333610Help talk:Style2014-09-03T11:14:21Z<p>Bwid: Programming Languages - Introductory Paragraph</p>
<hr />
<div>==Read this first==<br />
[[Help:Style]] is an official document of the ArchWiki, and it is actively monitored for malicious, unapproved, or poor quality edits. This is necessary to ensure sufficient stability over time, since frequent, undiscussed changes to its rules would defeat the purpose of the guide itself.<br />
<br />
It is probably needless to say that the active supervision of the article makes this very talk page the most important and effective place for discussing every possible improvement to the guide, from the correction of small typos to major changes like the introduction of new rules. Every report or discussion is welcome and will be answered as soon as possible. However, if an existing style rule is under dispute, its current state remains enforced until it is changed, if that ever happens.<br />
<br />
This guide was born after several months of discussions among the administrators and the most active contributors at the time, and it is a compromise among their ideas and those of who has been contributing until now. While new ideas and proposals that are coherent with the guide will probably be accepted and implemented, it is also likely that the requests that aim to radically change the way a particular style issue is already addressed will be discarded. We all must acknowledge the fact that it is reasonably unrealistic to think that all the ArchWiki users will ever completely agree over all the style rules, that is why it becomes necessary that final decisions be made by the administrators: we hope that this concept will be peacefully accepted by everybody, so that we can all collaborate in a more constructive way.<br />
<br />
Thank you for reading this notice and for contributing to the ArchWiki! -- [[ArchWiki:Administrators|The ArchWiki Administrators]] 21:27, 14 January 2012 (EST)<br />
<br />
{{Tip|A way to speed up the addition or modification of style rules is to provide some text that, if approved, can be directly copy-pasted in the guide, just like patches work for bug reports.}}<br />
__TOC__<br />
== Change Edit Summary label and possibility to make it mandatory ==<br />
<br />
All edits to articles should be accompanied by some words in the summary filed, answering the question "'''Why''' did you edit the article?". "What", "where", "when" and "how" are self-explained by the diff itself, it's redundant to add them. An explanation is not mandatory in talk pages, where the "why" should be already evident. Remember that links are allowed in the summary field, so it is allowed to point to an existing discussion. -- [[User:Kynikos|Kynikos]] 09:32, 3 May 2011 (EDT)<br />
<br />
Maybe we could submit a bug to request the change of the word "Summary:" to "Reason for editing:" next to the input in the edit page itself? -- [[User:Kynikos|Kynikos]] 11:33, 3 May 2011 (EDT)<br />
:+1<br />
:Would it go directly upstream? The Polish wiki has something like ''Summarize the changes [you've made to the article]''. Wikipedia has ''Edit summary <sub>(Briefly describe the changes you have made)</sub>''. They all deal with what is being changed, not '''why''' - we need to fix this :-) -- [[User:Karol|Karol]] 12:04, 3 May 2011 (EDT)<br />
::Done: {{Bug|24075}}, remember you can vote it. -- [[User:Kynikos|Kynikos]] 12:57, 3 May 2011 (EDT)<br />
:::Any wiki admin can change this message (aside: can you view [[Special:AllMessages]]?) I think it might be more fitting to include this as an addendum to the copyright notice instead (text above the summary field). Perhaps we should also consider making the edit summary mandatory (i.e. prevent saving with a blank summary). -- [[User:Pointone|pointone]] 22:55, 4 May 2011 (EDT)<br />
::::Nice, I can see that page, I didn't know that ^^ Maybe I should close the bug request then. Anyway I'm quite sure that ''only'' appending this recommendation to the copyright notice would make people start ignoring it very soon (as it happens with road signs eheh): I'm still in favour of changing the word "Summary", as it's misleading. Making the field mandatory could be a great idea instead, but for what I've seen until now, if the edit page returns an error, it forgets about the editing done, and it would be quite annoying (the textarea could be easily repopulated echoing $_POST['...'] instead of recovering the text back from the database; I have only tested this when trying to edit a page that has been edited by somebody else meanwhile). -- [[User:Kynikos|Kynikos]] 06:15, 5 May 2011 (EDT)<br />
::::(Well, doing it in javascript would solve the problem, though using JS is not very wiki-style it seems) -- [[User:Kynikos|Kynikos]] 06:17, 5 May 2011 (EDT)<br />
:::::When saving an edit that conflicts with another, your changes ''are'' saved. MediaWiki presents you with two text areas: one contains the page contents and the other contains your edit.<br />
:::::Either way, a quick Google search reveals [http://commons.wikimedia.org/wiki/User:DieBuche/forcesummary.js User:DieBuche/forcesummary.js] and [[Wikipedia:Wikipedia:WikiProject User scripts/Scripts/Force edit summary]] as two possible solutions. There also is a user preference option under '''Editing''' > '''Advanced options''' > '''Prompt me when entering a blank edit summary''' -- I wonder whether we can enable this option by default as a less-intrusive solution.<br />
:::::-- [[User:Pointone|pointone]] 09:16, 5 May 2011 (EDT)<br />
::::::Uhm it always looked like I lost my changes everytime I had edit conflicts (always easily recovered with the back button), anyway it could be that I didn't look well.<br />
::::::About the main topic, I would first try just to change the Summary text, anyway if you want to go the JS way immediately, do it in a way that the user understands that he has to answer the question "why", not "what", otherwise all edit summaries would probably be filled with "added section", "corrected code", "deleted section" and so on (well, those ''are'' summaries in the end, and that's what the form requests literally atm). -- [[User:Kynikos|Kynikos]] 11:07, 5 May 2011 (EDT)<br />
:::::::I think it's also OK to combine 'what' with 'why' e.g. '[https://wiki.archlinux.org/index.php?title=Arch_Based_Distributions_(Active)&diff=prev&oldid=139695 removed '''outdated''' links]'. I'm not a native English speaker, but it sounds more natural than 'links were outdated'. -- [[User:Karol|Karol]] 11:50, 6 May 2011 (EDT)<br />
::::::::Of course it's also ok, anyway I'm not a native speaker either, but if a label says "Reason for editing" it comes more natural to me to write "links were outdated". This system should also exploit a bit of psychology afterall. -- [[User:Kynikos|Kynikos]] 12:56, 6 May 2011 (EDT)<br />
:::::::::<facepalm> Of course you are absolutely right ... I - ummm - forgot that we wanted to change 'Summary' to 'Reason for editing'. Sorry about that. -- [[User:Karol|Karol]] 19:58, 8 May 2011 (EDT)<br />
:::Since the bug got closed as 'Upstream', do we go upstream with this? -- [[User:Karol|Karol]] 19:58, 8 May 2011 (EDT)<br />
::::I am curious whether this has been discussed upstream already... I have no problem with making the change on our end, since every wiki handles summary policy differently (as pointed-out above in examples). -- [[User:Pointone|pointone]] 22:46, 8 May 2011 (EDT)<br />
:::::Well you are the one in charge here, you can decide what to do now ;) -- [[User:Kynikos|Kynikos]] 05:53, 9 May 2011 (EDT)<br />
::::::The style part of this discussion has been implemented in the guide. I'd still be interested in changing "Summary" to "Reason for editing", anybody else? -- [[User:Kynikos|Kynikos]] 15:32, 21 September 2011 (EDT)<br />
:::::::Going upstream would benefit more that just our wiki, as mediawiki is a pretty popular piece of software. +1 from me. -- [[User:Karol|Karol]] 16:45, 21 September 2011 (EDT)<br />
::::::::The relevant system message is [[MediaWiki:Summary]]. I would suggest that the word "Summary" itself remain, as it is referenced in other locations and the documentation. My vote is for addition of an explanatory subtext à la Wikipedia. (Summary: <sub>(Briefly describe the changes you have made)</sub>). -- [[User:Pointone|pointone]] 13:50, 22 September 2011 (EDT)<br />
:::::::::Cooool, that's the way to go! +1000 XD<br />
:::::::::Some ideas:<br />
:::::::::*<sub>Briefly explain the reason for the changes you have made</sub><br />
:::::::::*<sub>Briefly explain the reason for your edit</sub><br />
:::::::::*<sub>Briefly explain the reason for your changes</sub><br />
:::::::::*<sub>Briefly explain the reason why you edited the page</sub><br />
:::::::::-- [[User:Kynikos|Kynikos]] 15:55, 22 September 2011 (EDT)<br />
::::::::::I think a combination of using explanatory text (I like something such as "<sub>Briefly explain the reason for your changes</sub>" from your suggestions), and investigating how to set "Prompt me when entering a blank edit summary" user option by default would make it more noticeable and be a great start here. [[User:Emiralle|Emiralle]] 12:56, 15 October 2011 (EDT)<br />
:::::::::::I'd like to make the edit summary strictly mandatory (meaning that a blank summary field won't allow submitting the edit): pointone mentioned some possible methods for doing this in the first part of the discussion, I'm just adding some more references as reminders (don't know exactly what to do with them yet... :P ): [http://www.mediawiki.org/wiki/Manual:$wgDefaultUserOptions] (see "forceeditsummary"), [http://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#Optional_additional_data], [http://www.mediawiki.org/wiki/Wikia_code/includes/EditPage.php]. -- [[User:Kynikos|Kynikos]] 15:01, 20 October 2011 (EDT)<br />
::::::::::::For the moment I've changed the label to:<br />
:::::::::::::[[Help:Style#Edit summary|'''Summary''']] <small>('''what''' you did and '''why''')</small>:<br />
::::::::::::as you can see when opening a page for edit, I hope it's ugly and annoying enough to be noticed by many >;)<br />
::::::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:37, 11 July 2013 (UTC)<br />
:::::::::::::The edit box has been moved to the right, so it's easy to spot that something's different. I like it, good job, Kynikos. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 19:14, 12 July 2013 (UTC)<br />
:::About making the ''Prompt me when entering a blank edit summary'' option enabled by default, this is what has to be done:<br />
:::# Have {{Bug|35545}} implemented<br />
:::# Edit [[MediaWiki:Missingsummary]] and make it more visible and formative<br />
:::# Add the {{ic|forceeditsummary}} option to the default user preferences as described in [[mw:Manual:$wgDefaultUserOptions]]<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:06, 13 July 2013 (UTC)<br />
<br />
==Article summary templates==<br />
See [[Help talk:Style/Article summary templates]].<br />
<br />
== Visited links color ==<br />
<br />
''[This sub-discussion stemmed as one of the several replies to [[#Style vs. Usability]]. Note that you may find some references to other sub-discussions that have been closed and removed. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:32, 27 July 2013 (UTC)]''<br />
<br />
Changing the color of visited links has been in my todo list for some time, maybe it's time to submit a bug for that: I'd like to see a purplish color, I tried something like <span style="color:#606;">#606</span>, <span style="color:#70b;">#70b</span>, <span style="color:#74b;">#74b</span>. More ideas? Objections?<br />
<br />
-- [[User:Kynikos|Kynikos]] 08:33, 19 January 2012 (EST)<br />
<br />
Note that interwiki links already become purple (albeit still too greyish?) when visited: [[wikipedia:Main Page]] '''[[wikipedia:Main Page]]'''. -- [[User:Kynikos|Kynikos]] 15:25, 24 January 2012 (EST)<br />
<br />
I'd also like to request that links remain bold even when they are in indented paragraphs ({{ic|#bodyContent dd > a {font-weight:bold;} }}?) -- [[User:Kynikos|Kynikos]] 11:46, 29 January 2012 (EST)<br />
<br />
:Completely agree. Also, I think, color should be different from one of interwiki links. --[[User:AlexanderR|AlexanderR]] 23:54, 29 January 2012 (EST)<br />
<br />
::Do you mean of a completely different color? Can you be more specific or give an example? In any case if there should be a difference in color among links, it should distinguish internal from external links (including interwiki).<br />
::However I think that black for normal text, blue for links (internal or external), purple for visited links and black on cyan for code may be already enough.<br />
::-- [[User:Kynikos|Kynikos]] 07:11, 31 January 2012 (EST)<br />
<br />
:::>> Do you mean of a completely different color?<br />
:::No, a bit darker shade than <span style="color:#606;">#606</span> (or, maybe even a bit more rich) would be perfect. --[[User:AlexanderR|AlexanderR]] 00:29, 4 February 2012 (EST)<br />
<br />
== Pkg and AUR templates: add icon, make them look different ==<br />
<br />
''[This sub-discussion stemmed as one of the several replies to [[#Style vs. Usability]]. Note that you may find some references to other sub-discussions that have been closed and removed. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:32, 27 July 2013 (UTC)]''<br />
<br />
More about visibility: we could <u>evaluate</u> (which means I'm not supporting yet this idea, i.e. I'm brainstorming) the possibility of adding a little inline package icon at the end of [[Template:Pkg]] and [[Template:AUR]] in a similar fashion to what happens with regular external links, that get a little arrow. Thoughts?<br />
<br />
I'm strongly against indentation as it won't work with installation requests that are included in longer sentences.<br />
<br />
-- [[User:Kynikos|Kynikos]] 08:33, 19 January 2012 (EST)<br />
<br />
If the icon for official packages is different from the one for aur packages, this may also let us avoid always adding "available in the [[official repositories]]" and "available in the [[AUR]]". -- [[User:Kynikos|Kynikos]] 11:46, 29 January 2012 (EST)<br />
<br />
:Well, if you find suitable icons. --[[User:AlexanderR|AlexanderR]] 23:54, 29 January 2012 (EST)<br />
:'''Edit:''' and develop alternative presentation for text browsers --[[User:AlexanderR|AlexanderR]] 23:54, 29 January 2012 (EST)<br />
<br />
::As an alternative to images, something like {{AUR|package}}<sup><small>[[AUR]]</small></sup> could be used. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:43, 24 July 2013 (UTC)<br />
<br />
:::We should also discuss, whether to change only AUR template, or also Pkg template. If we use {{AUR|package}}<sup><small>[[AUR]]</small></sup> style, I think it would be OK to let Pkg as is, but it would not allow to avoid "available in the [[official repositories]]". Adding "[[official repositories]]" into superscript for Pkg template is not possible because it's too long, perhaps some abbreviation could be introduced for this purpose.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:31, 24 July 2013 (UTC)<br />
<br />
::::The wording "available in the [[official repositories]]" was practically required only for consistency with the "available in the [[AUR]]" wording, but a link to [[official repositories]] is already in [[pacman]], and [[official repositories]] doesn't contain any useful information on how to install packages, as opposed to [[Arch User Repository]]. This is to say that we could leave [[Template:Pkg]] as it is, change [[Template:AUR]] to {{AUR|package}}<sup><small>[[AUR]]</small></sup> and stop requiring the "available in *" wordings.<br />
::::Note that just updating [[Template:AUR]] would make heaps of articles look weird, as they'd get two links to [[AUR]] very close to each other; a safer alternative could be:<br />
::::# copy [[Template:AUR]] to [[Template:AUR_temp]]<br />
::::# change all the current instances of [[Template:AUR]] to [[Template:AUR_temp]] using a bot<br />
::::# update [[Template:AUR]] to the new style<br />
::::# change all the instances of [[Template:AUR_temp]] back to [[Template:AUR]] manually, removing the "available in [[AUR]]" parts<br />
::::([[Template:AUR]] and [[Template:Aur]] are backlinked by almost [[Special:MostLinkedTemplates|1500 pages]] though)<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:03, 27 July 2013 (UTC)<br />
<br />
:::::I'm a bit late to the party, but I think this is the best and safest idea! As a side note, instead of {{ic|<nowiki>{{AUR_temp|package}}</nowiki>}}, we could maybe use something like {{ic|<nowiki>{{AUR|package|noicon}}</nowiki>}}, that can exist permanently, for use cases where the <sup><small>[[AUR]]</small></sup> is unwanted. -- [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 16:17, 9 July 2014 (UTC)<br />
<br />
::::::Unfortunately that's impossible to implement without any [[mw:Lua scripting|scripting]]. You'd need at least primitive condition clause to adapt the output based on whether the argument is defined or not. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:03, 9 July 2014 (UTC) <br />
<br />
:::::::Oh I'm sorry, I thought that functionality was built-in in MediaWiki. But if not, we could do {{ic|<nowiki>{{AUR|package}}</nowiki>}} and {{ic|<nowiki>{{AUR_noicon|package}}</nowiki>}}. -- [[User:Lonaowna|Lonaowna]] ([[User talk:Lonaowna|talk]]) 18:46, 9 July 2014 (UTC)<br />
<br />
::::::::I haven't tested it, but I think it would be possible to make [[Template:AUR]] hide the superscript with {{ic|<nowiki>{{AUR|package|}}</nowiki>}} (note the final pipe) or {{ic|<nowiki>{{AUR|package|noicon=}}</nowiki>}}, however for Simplicity I can't really think of any cases where we'd need that functionality.<br />
::::::::Putting that aside, I'd be ready to implement the plan I outlined above, but not before completing [[Help talk:Style/Article summary templates#Deprecation of summaries and overviews]] and [[Template talk:Wikipedia#Deprecation]].<br />
::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:25, 10 July 2014 (UTC)<br />
<br />
:::Other possibility could be to create separate templates for use in lists of applications, where the need to differentiate AUR and Pkg is obvious. I think it is not needed in article introductions etc., there are already phrases like "available in the [[official repositories]]" or "available in the [[AUR]]".<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:31, 24 July 2013 (UTC)<br />
<br />
::::I like the other idea more, for simplicity, however this alternative can of course be taken into consideration. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:03, 27 July 2013 (UTC)<br />
<br />
:::::It's a good solution to make it {{AUR|package}}<sup><small>[[AUR]]</small></sup>, because it has a good appearance and eliminates the need to write ''available in the *''. I think there's no need to use a separate template for [[List of applications]] or another articles, because such info (that package is in AUR) will never be reduntant. With this method we can leave [[Template:Pkg]] unchanged -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 15:01, 9 July 2014 (UTC)<br />
<br />
::::::Yeah, the idea about the separate template is discarded, let's focus on the other branch of this discussion above. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:30, 10 July 2014 (UTC)<br />
<br />
=== Recommended wording ===<br />
<br />
With a new template, offered by Kynikos, we must use another sentences to say about installing of packages. There're some options:<br />
<br />
# [[Arch User Repository#Installing packages|Install]] {{AUR|package}}<sup><small>[[AUR]]</small></sup><br />
# Install {{AUR|package}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup><br />
<br />
The second one have a link to section, not to a whole article.<br />
So, the first one is good, because that's the way of wording, recommended for packages from official repositories, but it has two links to the same article. The second one solves that issue, but in this case it will differ from wording of official packages. Opinions?<br />
<br />
P.S. Or maybe it will be better not to use a link to a particular section? If so, we can use the following wording:<br />
<br />
* [[pacman#Installing specific packages|Install]] {{Pkg|package}} - for official repositories<br />
* Install {{AUR|package}}<sup><small>[[AUR]]</small></sup><br />
<br />
-- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 13:02, 10 July 2014 (UTC)<br />
<br />
:I think we can indeed link to specific sections:<br />
:* {{ic|<nowiki>[[Install]] {{Pkg|package}}</nowiki>}} [[Install]] {{Pkg|package}}<br />
:* {{ic|<nowiki>Install {{AUR|package}}</nowiki>}} Install {{AUR|package}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup><br />
:Note the use of the [[Install]] redirect to pacman, which, besides being simpler, will allow easily updating all the links in case the relevant section in [[pacman]] is renamed; we may use it also for AUR packages, I think it wouldn't be confusing:<br />
:* {{ic|<nowiki>[[Install]] {{AUR|package}}</nowiki>}} [[Install]] {{AUR|package}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup><br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:54, 12 July 2014 (UTC)<br />
<br />
::I'm all for better templates, but keep in mind that {{ic|<nowiki><sup></nowiki>}} adds slight distance between previous and current lines, which looks slightly uglier to me. Compare:<br />
----<br />
::asdf safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad {{AUR|glfw3-git}} (CURRENT TEMPLATE) f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f {{AUR|glfw3-git}} asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads<br />
----<br />
::asdf safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad {{AUR|glfw3-git}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup> (NEW TEMPLATE) f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads {{AUR|glfw3-git}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup> fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad {{AUR|glfw3-git}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup> sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads safsadf asd f adsf sad fad sfdsa f ads fads f asd fdasfasf adsf das f dsaf ads fa fdas fdsa fdsaf asdd fasf sa fads dsf fads<br />
::[[User:Axper|axper]] ([[User talk:Axper|talk]]) 05:13, 12 July 2014 (UTC)<br />
<br />
:::True, thanks for mentioning it, however it's easily fixed with {{ic|<nowiki><sup style="line-height:0;"></nowiki>}}:<br />
:::<div style="border:1px dashed black;float:left;width:200px;margin-right:1em;">neio ien eoi ien eioie neoi ien eoi {{AUR|tsra}}<sup style="line-height:0;"><small>[[Arch User Repository#Installing packages|AUR]]</small></sup> ne ooien neoiien neoi ioen neoi oien ne ineo ien</div> <div style="border:1px dashed black;float:left;width:200px;">neio ien eoi ien eioie neoi ien eoi {{AUR|tsra}} ne ooien neoiien neoi ioen neoi oien ne ineo ien</div> <div style="clear:both;"></div><br />
:::If I remember well it works on all the major browsers.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:49, 12 July 2014 (UTC)<br />
<br />
::::Yeah looks good! (on Firefox) [[User:Axper|axper]] ([[User talk:Axper|talk]]) 06:02, 12 July 2014 (UTC)<br />
<br />
::About that: {{ic|<nowiki>[[Install]] {{AUR|package}}</nowiki>}} [[Install]] {{AUR|package}}<sup><small>[[Arch User Repository#Installing packages|AUR]]</small></sup><br />
::Oh no, think about ArchLinux's newcomers: they'll see a link to command {{ic|pacman -S ...}} (and it tells, that it's a command for installation of packages) and another link to a not-small list of incomprehensible actions. After that any newcomer will try to install AUR packages via {{ic|pacman -S}}<br />
::-- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 10:28, 16 July 2014 (UTC)<br />
<br />
:::Well this can make sense, besides users can learn to install AUR packages with makepkg -i which would avoid using pacman directly altogether. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:25, 17 July 2014 (UTC)<br />
<br />
== Daemons and modules ==<br />
===<s> Wording </s>===<br />
<br />
We need a more generic standard phrasing when requesting to "add daemons to the DAEMONS array..." (even avoid making reference to rc.conf, since [[Daemons]] links there already?) in the vein of what's been done with installation instructions, and point more clearly to [[Daemons]]. Similar problem with kernel modules and the MODULES array. Also the instructions for starting/stopping daemons and for adding/removing modules could be merged in the sentence.<br />
<br />
I'd like to start a brainstorming session here to find the right wording example(s) to put in the guide. Of course objections to the whole idea are still taken into consideration.<br />
<br />
We probably need a standard phrasing for immediate starting/stopping/loading/removing only, another standard for adding to DAEMONS/MODULES only and a third one for the cases where both immediate and automated action are recommended. I'll start with (I repeat, this is a brainstorming session):<br />
<br />
*"[[Daemons#Performing daemon actions manually|Start]] the {{ic|foobar}} daemon."<br />
*"[[Kernel Modules#Loading|Load]] the {{ic|foobar}} module."<br />
*"Add the {{ic|foobar}} daemon to the [[Daemons#Starting on Boot|DAEMONS]] array."<br />
*"Add the {{ic|foobar}} module to the [[Rc.conf#Hardware|MODULES]] array."<br />
*"[[Daemons#Performing daemon actions manually|Start]] the {{ic|foobar}} daemon and add it to the [[Daemons#Starting on Boot|DAEMONS]] array."<br />
*"[[Kernel Modules#Loading|Load]] the {{ic|foobar}} module and add it to the [[Rc.conf#Hardware|MODULES]] array."<br />
<br />
Note that if we solve the problem of links color and font-weight as explained at the bottom of [[#Style vs. Usability]], the links will always be blue/purple and bold, even in indented paragraphs. For now you can fake this effect by enclosing links in {{ic|<nowiki>'''</nowiki>}}.<br />
<br />
-- [[User:Kynikos|Kynikos]] 16:17, 31 January 2012 (EST)<br />
:* I moved this part to the separate section as this discussion is not directly related to "formatting bloat" but rather to unification of phrasing.<br />
:* Exact formatting depends on results of [[#Bold and italic]] discussion, so I propose to finish it before continuing this one.<br />
:>> objections to the whole idea are still taken into consideration<br />
:Well, I have already understood reasons for deprecating installation instructions and modules loading at startup/daemons autostart. All this is performed only once and there are a lot of troubles with giving command line snippets for this. But what's wrong with starting/stopping daemons? I'd better suggest to allow usage of snippets for this purpose but only for other reasons than creation of whole "Starting xxx manually" section, containing only that single line of code. IMHO, it is usually enough to mention existence and purpose of daemon in given package and providing link to [[Daemon]]. All daemons behave similarly, interaction with them in Arch is really simple; there is simply no need for adding same sections with same contents for ''every'' article. If writing snippet is really required to maintain workflow of step-by-step guide, then there is probably no need for restricting it (the same for loading/unloading) modules.<br />
:--[[User:AlexanderR|AlexanderR]] 19:44, 31 January 2012 (EST)<br />
::Eheh with "whole idea" I meant the idea expressed in the first paragraph, since I was asking for possible methods of applying it without apparently leaving room for objections. I admit it wasn't clear at all :) So, just to give you an answer, it would look a bit inconsistent to me to allow daemon starting/stopping instructions and not installation instructions, also because we should resort to using snippets like:<br />
:::You must now start the '''whatever''' daemon:<br />
:::{{bc|# rc.d start whatever}}<br />
::Which looks redundant to me, unless you wanted to suggest something like:<br />
:::Now run:<br />
:::{{bc|# rc.d start whatever}}<br />
::Which I like even less because it's not teaching anything, it just leads the inexperienced user to copy-paste the command, without thinking of what he's doing.<br />
::If you had something different in mind, just give an example. -- [[User:Kynikos|Kynikos]] 18:20, 3 February 2012 (EST)<br />
:::Again from [[PulseAudio]]:<br />
:::{{Box||If the D-Bus system daemon is not already running, start it:{{bc|# rc.d start dbus}}<br>PulseAudio can be started with:{{bc|$ pulseaudio --start}}<br>Or if you use X11:{{bc|$ start-pulseaudio-x11}}}}<br />
:::Lets break workflow:<br />
:::{{Box||PulseAudio depends on '''dbus''' [[daemon]], so first run it.<br>PulseAudio can be started with:{{bc|$ pulseaudio --start}}<br>Or if you use X11:{{bc|$ start-pulseaudio-x11}}}}<br />
:::What looks better? --[[User:AlexanderR|AlexanderR]] 00:37, 4 February 2012 (EST)<br />
::::This argument seems rather circular. I fully support the last comment by Kynikos. And personally, I would combine the first two sentences in AlexanderR's second example to something like:<br />
:::::Since PulseAudio depends on the {{ic|dbus}} daemon, [[Daemon|start]] dbus and then start PulseAudio:<br />
::::~ [[User:Filam|Filam]] 22:43, 4 February 2012 (EST)<br />
:::::Like this?<br />
:::::{{Box||Since PulseAudio depends on the {{ic|dbus}} daemon, [[Daemon|start]] dbus and then start PulseAudio:{{bc|$ pulseaudio --start}}<br>Or if you use X11:{{bc|$ start-pulseaudio-x11}}}}<br />
:::::[[Wikipedia:Looks|Looks]] nice, except usage of verb in link to [[daemon]] article: I [[Wikipedia:agree|agree]] with [[User:Vadmium]] about the fact that usage of such [[Wikipedia:WP:easter_egg|easter_egg]] links [[Wikipedia:can|can]] a bit annoying and sometimes even misleading.<br />
:::::PS I am not going to challenge already reached agreement on deprecation of daemon instructions, so please consider adding something useful to [[#Quoting and underlining]] and [[#Bold and italic]] discussions, so that we can continue this one. --[[User:AlexanderR|AlexanderR]] 00:40, 5 February 2012 (EST)<br />
<br />
::::::Since we mentioned services in [[Help:Reading]], using "easter egg" links in these cases should be ok, just like we're doing with installation instructions (we're not writing "install {{Pkg|somepackage}} with [[pacman]]"). I'm closing this discussion, the rest should be handled by the discussions below. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:01, 30 August 2014 (UTC)<br />
<br />
===<s> Daemon operations </s>===<br />
I'd like to suggest you / we add wording & style suggestions for systemd daemon operations to [[Help:Style#Daemon_operations]]. --[[User:Stefanwilkens]]<br />
<br />
:Agreed, can you start with an example of suggestions? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:58, 3 October 2012 (UTC)<br />
::Considering that giving direct examples that can be copy pasted is deprecated, I would suggest something like this:<br />
::Use [[Systemd#Using_Units|systemctl]] to enable <servicename> with <servicefile> during boot.<br />
::{{Note|Use [[Systemd#Using_Units|systemctl]] to enable GDM with {{ic|gdm.service}} during boot.}}<br />
::Or the more to the point:<br />
::<Action> <servicename> with <servicefile> using [[Systemd#Using_Units|systemctl]].<br />
::{{Note|Start GDM with {{ic|gdm.service}} using [[Systemd#Using_Units|systemctl]].}}<br />
::{{Note|Enable GDM at boot time with {{ic|gdm.service}} using [[Systemd#Using_Units|systemctl]].}}<br />
::Upon review of this, it seems that we may only have to adjust the references to rc.d and the old DAEMONS array from [[Help:Style#Daemon_operations]] and replace it with instructions fitting to systemd. For example:<br />
:::'''Daemon operations'''<br />
:::* The standard phrasing is a simple list of the daemons involved, possibly remarking dependencies or conflicts with other daemons, and a link to [[Daemon|Daemon]].<br />
:::* If a required action is not covered in [[Daemon|Daemon.]], it is acceptable to provide an example. Such an example should make use of the {{ic|systemctl}} command and provide a listing of the service files involved.<br />
:::* The Beginners' Guide and its subpages are the only exceptions to the rules above.<br />
::Just suggestions to get the ball rolling, nothing is worse that outdated documentation. --[[User:Stefanwilkens|stefanwilkens]] ([[User talk:Stefanwilkens|talk]]) 18:25, 14 October 2012 (UTC)<br />
<br />
:::Wrt [[#Passing arguments to systemd units: give example commands or not?]], here are a few suggestions to control [[systemd#Using units|instantiated units]]:<br />
:::{{Box||The {{ic|rfkill-block@.service}} [[systemd#Using units|template unit]] can be used to block given device type at boot, for example {{ic|rfkill-block@bluetooth.service}}.}}<br />
:::{{Box||To enable automatic switching of ''netctl'' profiles on a wireless interface, enable the {{ic|netctl-auto@.service}} [[systemd#Using units|template unit]]'s instance, for example {{ic|netctl-auto@wlan0.service}}.}}<br />
:::If the term "template unit" will catch on, we could create a redirect for it to simplify the linking.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:15, 23 August 2014 (UTC)<br />
<br />
::::I don't know, I've implemented my idea directly in [[Help:Style#Systemd units operations]] so we have something more tangible to work on (yes, I've also updated the heading, as the word "daemon" seems to have fallen a bit into disuse, replaced by "service", "unit" etc.).<br />
::::Regarding your proposal, I'd like to keep using the same kind of word as the anchor text for the link to [[systemd]], for consistency (i.e. the ''systemctl'' action). Then I'd avoid to use both "template" and "instance" in the same sentence, which sounds a bit redundant: it should be enough to say, more concisely, something like "an instance of {{ic|unit@.suffix}}".<br />
::::What do you think?<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:47, 26 August 2014 (UTC)<br />
<br />
:::::Your version is simpler indeed, I have no objections. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:08, 26 August 2014 (UTC)<br />
<br />
::::::Thanks, I'm closing this discussion then: perhaps the rules/examples may be improved further, but let's use new discussions for that when somebody comes up with a good idea. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:06, 30 August 2014 (UTC)<br />
<br />
=== Passing arguments to systemd units: give example commands or not? ===<br />
<br />
About [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=319448&oldid=319444], [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=next&oldid=319448] and [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=next&oldid=319449]: the current version makes it look like there is a file {{ic|dhcpcd@''interface_name''.service}} somewhere in the file system, the following sentence tries to explain that it is just an argument. IMO the original version was all clearer, more accurate and shorter, so I wonder if we can tolerate ''giving examples of how to manipulate systemd units taking arguments'', excepting it from the current rule. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:29, 26 June 2014 (UTC)<br />
<br />
:Are [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=321632&oldid=321570] and [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=321634&oldid=321632] clearer? Perhaps it would be easier to add a paragraph to [[systemd#Using_units]] explaining arguments, rather than add an exception. After all, many {{ic|.service}} files take arguments; on my install:<br />
<br />
:{{bc|<nowiki><br />
$ locate "@.service" | wc -l<br />
48<br />
</nowiki>}}<br />
<br />
:--[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:32, 26 June 2014 (UTC)<br />
<br />
::Oh well, the rule on daemons has certainly been one of the most controversial through time, it was originally designed for rc.d scripts [https://wiki.archlinux.org/index.php?title=Help:Style&oldid=163286#Daemon_operations] and after the switch to systemd it was only "translated", without doing any other adaptations.<br />
::systemd is certainly more powerful and we should start keeping that into account: I like Alad's idea, we should introduce unit '''instances''' (not "arguments") in [[systemd]], also for educational purposes, without excepting the style rule. I would seriously consider adding brief systemd guidelines to [[Help:Reading]] (or maybe just a link to [[systemd]]). Finally we should add well-designed wording examples to [[Help:Style#Daemon operations]] (see discussions above), like we've done for installation instructions: in case of unit instances we should use the word "instance" (or whatever word we decide to use) to link to the newly created section in [[systemd]].<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:18, 28 June 2014 (UTC)<br />
<br />
:::I was quite surprised to find out that the description of ''instantiated units'' is missing in [[systemd]] (I guess Archers are fine with man page). I agree that there should be at least a short intro, something we can link to. [https://coreos.com/docs/launching-containers/launching/getting-started-with-systemd/#instantiated-units This] looks nice, we could put together something similar. And use more external links of course, unfortunately I can't access [http://0pointer.de/blog/projects/systemd.html Lennart Poettering's blog], which as far as I remember described it quite well. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:59, 29 June 2014 (UTC)<br />
<br />
::::Lennart's site seems to go down intermittently, right now it works again... --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:10, 29 June 2014 (UTC)<br />
<br />
:::::Marked [[Systemd#Using units]] for expansion. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:58, 30 June 2014 (UTC)<br />
<br />
::::::I would leave it with a bullet for mentioning "instantiated" in that section and had a go on it (please check): [https://wiki.archlinux.org/index.php?title=Systemd&diff=331763&oldid=331698]. <br />
::::::Perhaps one of the instantiated ones most troublesome for users could be used as an item in [[Systemd#Troubleshooting]] to give a practical example? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:27, 21 August 2014 (UTC)<br />
<br />
:::::::I've improved the bullet point a bit and removed the Expansion flag.<br />
:::::::About [[Systemd#Troubleshooting]], would you use a unit instance in place of {{ic|systemd-modules-load}}? Maybe that can be discussed in [[Talk:Systemd]], honestly I'd be neutral about it.<br />
:::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:53, 23 August 2014 (UTC)<br />
<br />
::::::::I think that the current note is OK, thank you both for implementing it. From the first Kynikos' reply, we have yet to add recommended wording(s) to [[Help:Style#Daemon operations]]. I will add some suggestions for enabling instantiated units into [[#Daemon operations]].<br />
::::::::Wrt adding brief systemd guidelines into [[Help:Reading]], the same could be done for installing packages (and loading kernel modules and similar). Given that there will always be an explicit link to "[[pacman|install]]" or "[[systemd#Using units|enable]]" or "[[Kernel modules|load]]", things are pretty simple for the reader: they either know and do as being told, or just follow the link. [[Help:Reading#Append.2C_create.2C_edit_and_source|Editing config files]] is different in that there is not any accompanying link, hence the entry in [[Help:Reading]]. We could describe the Hypertext metaphor there, but I think that unlike editors, readers tend to follow it naturally.<br />
::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:27, 23 August 2014 (UTC)<br />
<br />
:::::::::Well, I was still thinking that some words in [[Help:Reading]] could fit the purpose of that article, also because it's linked from [[Main page#Help]] and it looked a bit incomplete without those basic examples, so I've gone ahead and added them, feedback is welcome. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:04, 25 August 2014 (UTC)<br />
<br />
::::::::::Reads perfect. Two small suggestions: under "$makepkg -si" I would add "to create and install the package with required dependencies.". Then, due to frequent usage, I would add ", ''enable''" to the first sentence [[Help:Reading#Control_of_systemd_units|here]]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:45, 26 August 2014 (UTC)<br />
<br />
:::::::::::Right, I've added "enable", but about makepkg I won't take action because [[Help:Reading]] is not really meant to give explanations, for that there are the main articles like [[AUR]] and [[makepkg]].<br />
:::::::::::Branch closed. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:20, 30 August 2014 (UTC)<br />
<br />
:Re Lahwaacz's original item I agree that using real examples instead of fictionary variables should avoid confusion, and now we have background explanation of "instances". I have edited the exemplified article with: [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=332005&oldid=322226], [https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=332006&oldid=332005]. Works? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:39, 23 August 2014 (UTC)<br />
<br />
::Looks good to me, thanks for updating it. Regarding interface names, I'd suggest using the "old-school" names ({{ic|eth0}}, {{ic|wlan0}} etc.) as a transition between the predictable names ({{ic|enp0s25}} and similar/worse atrocities) and pseudo-variables ({{ic|''interface''}}, {{ic|''client_side_interface''}} etc.) because out of these three, the "old-school" names are probably the easiest to understand. If an appropriate note linking to [[Network configuration#Device names]] and stating the conventions '''for the given article''' is provided, even the users used to the predictable names should understand just fine. Also, [[Internet sharing]] uses a profound convention and introduces fictional interfaces {{ic|net0}} and {{ic|internet0}} to avoid long pseudo-variables like {{ic|''wan_interface''}} and {{ic|''client_side_interface''}}, so I don't mind fictional interface names either. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:19, 23 August 2014 (UTC)<br />
<br />
:::Well, one reason articles like [[Internet sharing]] introduced fictional names was also that they required interface persistence before predictable names were introduced. It's always context that makes one or the other seem more useful and, like you say, stating conventions. For example, I believe it's very important article's like the BG guide use predictable names, and explain them like they do. However, using those everywhere gets really awkwardly inconsistent over time, because if content gets gradually edited it's obvious that a command line output from editor2 will show another interface than the output in the paragraph above. That's another reason why I'm fully +1 with your suggestions. Let's see we keep it consistent in article context, conventions stated/crosslinked as applicable and prefer easy to grasp/recognisable short forms. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:46, 24 August 2014 (UTC)<br />
<br />
::::So, I'm a bit neutral here, do we want to explicitly invite to be consistent throughout each article without recommending any kind of name types? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:20, 30 August 2014 (UTC)<br />
<br />
=== Remove the rules on modules? ===<br />
<br />
The need for [[Help:Style#Kernel modules operations]] descends from the initscripts times, when the modules to be loaded had to be listed in rc.conf and it was too repetitive to always say how to edit that file. However, systemd and udev have made the need to explicitly load modules much more infrequent, so I'm wondering if we really still need those style rules, or if instead we can remove them and allow writing simple module loading instructions where specifically required. A link to [[kernel modules]] would still be encouraged by [[Help:Style#Hypertext metaphor]].<br />
<br />
In case it wasn't clear enough, I'm for removing the section.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:58, 26 August 2014 (UTC)<br />
<br />
== Better structuring ==<br />
<br />
IMHO, many parts of article can be safely moved to descriptions of corresponding templates. For example, information about [[Template:Keypress]] actually belongs to template itself rather than this style guidelines. I believe, most people look at template page before using it. What do you think? --[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
:Actually this idea would overlap with a larger project I've had in mind for some time now: merging editing and style guidelines consistently everywhere, and split them in several articles based on the various topics being dealt with. However I'd like to plan this carefully in advance, as it involves several pages, otherwise we risk increasing the mess instead of reducing it. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:04, 14 May 2012 (UTC)<br />
::> ..merging editing and style guidelines consistently everywhere, and split them in several articles based on the various topics being dealt with.<br />
::Sounds good. Note, that moving part of current content to templates can reduce overall size of all involved articles and possibly simplify further work. --[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
:See also [[#Help:Talk]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:11, 25 December 2012 (UTC)<br />
<br />
I was wondering, why the style guidelines are kept in the ''Help:'' namespace? I think that ''ArchWiki:'' would suit the rules better, then ''Help:'' could be reserved for examples, recommendations and guides (not guidelines). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:30, 23 August 2014 (UTC)<br />
<br />
:But with that reasoning nothing would be left in [[:Category:Help]] ^^ I know you're making the comparison with [[Wikipedia:Wikipedia:MoS]], I'm not aware of Wikipedia's policy about the scope of the two namespaces (but I've seen many Wikipedia:... articles under the Help category there, either directly or under a descendant, while Category:Wikipedia seems to contain articles that talk about Wikipedia in an encyclopedic way, and they're not in the Wikipedia's namespace).<br />
:In our wiki, I think we tend to have a correspondence (or redundancy) between the Help and ArchWiki namespaces and categories: Help is more for articles that are meant to show editors the proper way to contribute (and so yes, for coherence I'd move [[ArchWiki:Contributing]] there instead), and ArchWiki is more for articles that are about the wiki itself (not Arch Linux), including the pages that are used by the staff to ease maintenance. Also note that [[:Category:Help]] is a child of [[:Category:ArchWiki]].<br />
:In short, I'd leave Style where it is, and maybe I'd improve the correspondence between namespaces and categories, thus moving [[Table of contents]] under ArchWiki:, together with [[ArchWiki Translation Team]], and then there are also some uncategorized titles in [[Special:PrefixIndex/ArchWiki:]], we could consider categorizing them.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:20, 25 August 2014 (UTC)<br />
<br />
== Related links ==<br />
<br />
=== See also or Related in Article Summary? ===<br />
<br />
I think we'd better be coherent whether to keep links, references etc. either in a "See also" section at the bottom of the article, or in one (or more) boxes under the Article Summary at the top right of the article.<br />
<br />
See also [[#Article summary templates]].<br />
<br />
-- [[User:Kynikos|Kynikos]] 15:15, 21 September 2011 (EDT)<br />
<br />
:This is more a reminder than other, but I'm starting to like the idea of adding the rule to keep related ArchWiki articles in the Article Summary box only, and external links in See also sections only. Well, this way the "See also" default may even be changed (with bots, don't worry!) to a non-imperative, descriptive title like "Additional resources", "External links" or something like that. -- [[User:Kynikos|Kynikos]] 07:06, 14 December 2011 (EST)<br />
:Also remember that many external links in summaries can be found with [[Special:WhatLinksHere/Template:Article_summary_link]]. -- [[User:Kynikos|Kynikos]] 07:41, 24 January 2012 (EST)<br />
<br />
'''Advantages of links in See also:'''<br />
*There is more space for link descriptions<br />
*It is likely one will read or skim the article before actively looking for additional reading material. This naturally leaves the reader at the end of the article. It is convenient for the reader in this case if links are at the end of the article. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*It ''seems'' more common (elsewhere) to have links at the end of articles (when they are not inline with the rest of the text). Following common convention it may be better from a usability perspective. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*:Especially for people used to Wikipedia, which uses the same wiki software. [[User:Vadmium|Vadmium]] 11:12, 26 October 2011 (EDT).<br />
*I am not sure how much we care about this but it having the links at the end could be more friendly to small form factor screens and screen readers. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*As a section, "See also" gets its own TOC entry granting easy access from near the top of the article. Alternatively one may press the END key. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*More formatting options here than in summary. [[User:Emiralle|Emiralle]] 13:12, 15 October 2011 (EDT)<br />
*More inclined to put external, or less closely related stuff here. [[User:Emiralle|Emiralle]] 13:12, 15 October 2011 (EDT)<br />
*''See also'' section would not be skipped if you start reading the main text sequentially from the top. [[User:Vadmium|Vadmium]].<br />
*''[add more advantages...]''<br />
<br />
'''Advantages of links in Article Summary:'''<br />
*Immediately visible<br />
*Beyond some minor editing inconvenience, is there any real disadvantage of having the most ''interesting'' links in both locations? It could be advantageous for the reader to have some links in both locations. [[User:James Eder|James Eder]] 00:29, 22 September 2011 (EDT)<br />
*I think putting very closely related links in the summary gives the topic more cohesion, and as James Eder said, they could be included at the bottom as well. [[User:Emiralle|Emiralle]] 13:12, 15 October 2011 (EDT)<br />
*It would theoretically be more effective in preventing duplication of content within the wiki, as (unexperienced) editors would have a clearer view of the articles where related content could already exist (true especially with series (or "rings") of articles on the same subject). -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:46, 29 September 2013 (UTC)<br />
*''[add more advantages...]''<br />
<br />
=== Lists ===<br />
Inspired by [https://wiki.archlinux.org/index.php?title=Sound_system&curid=10626&diff=201543&oldid=197917], I was wondering if related links in "See also" sections or article summaries should be avoided if already present in the body of the article. I'd prefer having complete lists of related articles even if that implies duplicating some of them. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:09, 16 May 2012 (UTC)<br />
:> I'd prefer having complete lists of related articles even if that implies duplicating some of them<br />
:I'd prefer this way as well. Sadly listing ''all'' related articles may occupy most of vertical space, so there should be clear guidelines regarding choise of related links. And editors often don't have time to read even [[Help:Style]]... On the other hand, defining simple rule like "only links not present in text" can eliminate the very requirement for any additional rules. --[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
:: "only links not present in text" is too strict I think. Related links make some page more "visible" to readers. For example, I often click on them to learn more info about the same topic. But to be honest, I rarely click on the "in page links" even the links shown clearly in "See Also". They are much harder to be found and clicked. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 04:50, 19 May 2012 (UTC)<br />
<br />
=== Definition ===<br />
Inspired by [https://wiki.archlinux.org/index.php?title=Boot_Debugging&diff=prev&oldid=201554], I was wondering if we needed a definition of what are the conditions under which an article can be considered related to another one. Honestly I can't think of something suitable at the moment, if somebody has good ideas, they're welcome here. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:09, 16 May 2012 (UTC)<br />
:Few ideas:<br />
:* Alternatives to software, described in article<br />
:* Methods and techniques alternative to ones described in article<br />
:* Software <-> it's use case<br />
:* software/technique <-> it's developer<br />
:--[[User:AlexanderR|AlexanderR]] ([[User talk:AlexanderR|talk]])<br />
<br />
== Application name capitalization ==<br />
<br />
Which are the rules of capitalization of certain names? For LibreOffice there is no doubt, but for example is it 'bash' or 'Bash'? Probably the documented one is the preferable, so 'bash', 'Bash' when starts a sentence, aria2c everywhere. For zsh neither man pages are coherent. -- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 18:00, 19 May 2013 (UTC)<br />
<br />
:This topic is rather interesting: it's quite natural that we should follow the capitalization used in the upstream documentation, and this guide should probably mention it. I'd also like to remark whether the name should be always capitalized at the beginning of a sentence or not: honestly my position would be to still follow what the upstream documentation does.<br />
:In case the documentation is not coherent, I guess there's nothing we can suggest, except for being consistent throughout the article, _and_, if the application is mentioned in other articles, capitalization should be consistently based on the main article for that application (e.g. [[Bash]]).<br />
:Note that Bash is always capitalized in http://www.gnu.org/software/bash/<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:00, 22 May 2013 (UTC)<br />
::so Bash is written wrong in [[Help:Style#Shells]], (lol, forgive me :) ) -- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 10:29, 3 June 2013 (UTC)<br />
:::Ahah perfection is unreachable, you will always find something to report... Anyway in this case "bash" _would_be_ written "wrong" in [[Help:Style#Shells]] only if the above had already been enforced as a rule ;) (but I'll forgive you for this blunder, don't worry :P ) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:32, 3 June 2013 (UTC)<br />
<br />
::::I like the way the Git project uses both "Git" and "git" in their documentation based on what the author is referring to. They use "Git" when talking about the project/software generally, and they use "git" when referring to the ''compiled program used when running commands'' [https://github.com/git/git/blob/master/Documentation/CodingGuidelines#L313]. This style makes it quite easy to know whether to use "Bash" or "bash", etc.<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:42, 11 January 2014 (UTC)<br />
<br />
:::::That is certainly logical, with [[Help:Style/Formatting_and_Punctuation]] applied it would be "Git" (plain text, first letter uppercase) and "''git''" (italic, all lowercase). I believe that with proper context it would not be confusing, but for the controversial cases it's probably best to place a note with some explanation into the talk page, as it has been done for [[Btrfs]]: [https://wiki.archlinux.org/index.php?title=Talk:Btrfs&diff=291780&oldid=291779]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:09, 31 January 2014 (UTC)<br />
<br />
::::::In my view Git makes its spelling convention look more complicated than it is: IMHO it just says "always use 'Git', except when talking about the executable, which is a lower-case filename and couldn't be run otherwise". Anyway we could indeed enforce such a convention, but only for applications that A) don't have an official or common capitalization convention and B) are commonly run through an executable that has the same name as the application itself. This would of course settle Bash and Btrfs cases though. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:50, 1 February 2014 (UTC)<br />
<br />
==List of Applications and See also==<br />
# I suggest for lists like [[List_of_Applications/Multimedia]] to use capital letter for the first letter of the description, NO dots at the end (this behaviour seems to be preminent in Wikipedia) and to avoid totally articles ('A ..' is annoying). Is it ok?<br />
# In the same list it may be fair to put <nowiki>{{Grp|group}}</nowiki> beside items that have their one.<br />
# The '''See also''' section should be treated as above lists.<br />
<br />
-- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 18:00, 19 May 2013 (UTC)<br />
<br />
:I support 1. and 2. except for the dots at the end of descriptions, which I would require instead, since sometimes the App template has long descriptions, even made of several sentences, and including all the puntuation only omitting the final dot would look weird to me.<br />
:About 3. I don't understand what you mean, can you be more specific?<br />
:However I'm also wondering if these rules should be hosted here (if they refer to the use of Template:App) or in [[Talk:List of Applications]] (if they refer only to [[List of Applications]] and subpages).<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:23, 26 May 2013 (UTC)<br />
::About 3: I just mean that a section like [[Aria2#See_also]] must have capitalized letters and no dots (or whatever the standard would be).<br />
::About the hosting place: page like [[CD_Burning#Burning_CDs_with_a_GUI]] or [[Conky#AUR_packages]] are not directly related to [[List of Applications]], so I think it is worth to host a rule here. Plus this rule would apply also to any other list, like [[E4rat#Process]] --[[User:Flu|Flu]] ([[User talk:Flu|talk]]) 16:53, 26 May 2013 (UTC)<br />
:::Still about 3: I see, usually See-also links have much shorter descriptions, in that case I would apply a no-dot policy. Still open to more opinions though.<br />
:::Hosting place: a rule about lists of applications would probably best fit in [[Template:App]], also in light of my plans to decentralize style rules in general. A rule about See also sections would instead fit this guide indeed, at least for the moment.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:17, 28 May 2013 (UTC)<br />
<br />
== One link to the package in a paragraph is enough ==<br />
Do we need multiple links to the same package, wiki article etc. in the same paragraph? I understand that if the article is very long, the links may be used in different sections, but isn't "[[Arch_Boot_Process#Init_process|In the past, Arch used SysVinit as the init process. Now on new installs, Systemd is used by default. Existing SysVinit users are recommended to switch to systemd.]]" with 2 links to SysVinit and 2 links to systemd a bit too much? -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 23:15, 21 May 2013 (UTC)<br />
:First thing, probably in the title you mean links to articles in general, not only packages, right?<br />
:However, I definitely agree, I guess we could extend the rule to the same section or even the whole article, but I'd like to exclude some cases, like "See also" sections (see [[#Lists of related links]]), and to make the rule compatible with [[Help:Style#Official packages]] and similar.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:11, 22 May 2013 (UTC)<br />
::Just a reminder: this is affected by [[Help:Style/Formatting_and_Punctuation#First_instances]], not sure if it sould be mentioned directly on [[Help:Style]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:35, 1 September 2013 (UTC)<br />
<br />
== Red links ==<br />
Is creating links to nonexistent wiki articles a good thing because it encourages creation of [[Special:WantedPages|wanted pages]]? Is [https://wiki.archlinux.org/index.php?title=Getty&oldid=258135#Others this] OK or a bit too red? [https://wiki.archlinux.org/index.php/Template_talk:App One discussion] asserted that it's OK to create red links when using the app template, but I don't like them and I'd prefer not to litter articles with references to non-existent articles. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 13:12, 24 May 2013 (UTC)<br />
: I remember reading something like "Only add links to nonexisting wiki articles when you intend to add it soon". Forget where did I read it, but I agree with it. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 04:59, 25 May 2013 (UTC)<br />
::Fengchao's unknown quote doesn't sound bad to me either. This wasn't the central topic in [[Template talk:App#Introducing default argument]] by the way (that discussion is still valid, though). -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:39, 2 June 2013 (UTC)<br />
:::I removed the red links that were in English articles. Closing. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 22:03, 12 July 2013 (UTC)<br />
::::Reopening, I will add "Only add links to nonexisting wiki articles when you intend to add it soon" somewhere. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:16, 13 July 2013 (UTC)<br />
<br />
== Prefer linking to the article than to the package ==<br />
''When mentioning an application, prefer linking to its article, if existing, rather than directly to the package.'' -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:24, 28 May 2013 (UTC)<br />
:+1, apart from the standard "Download {{ic|foo}} from the official repos" and similar. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 13:27, 28 May 2013 (UTC)<br />
<br />
== git/vcs/source builds ==<br />
<br />
In some article there are source build instruction like [[Jumanji#Method_2:_From_Source]] and [https://wiki.archlinux.org/index.php?title=Logitech_Unifying_Receive&direction=prev&oldid=260677#From_AUR] or AUR git references like [https://wiki.archlinux.org/index.php?title=Bumblebee&oldid=259841#Installation]. I think they are pointless because:<br />
* of course you can build application on your own, there is no need to say that.<br />
* there is plenty of git/patched/vcs variants in AUR. One can decide to install them by their choice.<br />
What about a rule to forbid git/source references unless they are the only chance?<br />
::(oh no, another time) -- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 21:15, 2 June 2013 (UTC)<br />
:IMHO 'make && make install' instructions should go.<br />
:I have nothing against describing different AUR packages, whether VCS or not. PKGBUILDs are sometimes pretty complex and it's not obvious what's the difference between the various AUR versions of a package - if any.<br />
:Please sign your talk page edits [[Help:Discussion#Join_a_discussion]]. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 20:21, 2 June 2013 (UTC)<br />
::Yes, manual compilation instructions can be removed, but ''only'' when an AUR package is available. A rule may be added for this.<br />
::No, please don't remove links to "alternative" versions of packages in [[AUR]]; treat every AUR package as the others, there are not AUR packages more "official" than others: if they all install the same application, they _can_ (i.e. ''not'' _must_) be mentioned in the same article.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:05, 3 June 2013 (UTC)<br />
::Just mentioning a recent related example, [https://wiki.archlinux.org/index.php?title=Isync&diff=262333&oldid=253631], that I consider perfectly reasonable. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:10, 12 June 2013 (UTC)<br />
<br />
==<s> Ellipses in code examples </s>==<br />
<br />
Reminder: mention ellipsis as an allowed form of extraneous code in examples; [[Help:Style#Command line text]] is already forbidding comments next to commands and we're going to add formatting style rules for "pseudo-variables". -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:21, 13 July 2013 (UTC)<br />
<br />
:Implemented in [[Help:Style#Code formatting]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:03, 27 August 2014 (UTC)<br />
<br />
== Talk pages of redirects ==<br />
''[moved from [[User talk:Kynikos#Talk pages of redirects]] -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:01, 22 August 2013 (UTC)]''<br />
<br />
I didn't find any rule/official policy regarding talk pages of redirects, but you made me think about it.<sup>[https://wiki.archlinux.org/index.php?title=Special%3ALog&type=delete&page=Talk%3AXMPP]</sup> Should they be deleted (of course with the exception of actual issue regarding the redirect)? What would that mean for users (non-admins) - should the talk page be marked for deletion? Or explicitly ask some admin to delete it? Or should the talk page be just blanked (assuming all issues were solved before the redirect)? I ask because now I realized that I left quite a mess behind me when I redirected some pages. Anyway, I think that some specific instructions to either [[Help:Style#Redirect pages]] or [[Help:Editing#Redirects]] won't hurt. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:41, 21 August 2013 (UTC)<br />
<br />
:It's true, there's no written policy on this matter. Blanking a page is not an option in any case. If the redirect target's talk page doesn't exist, the redirect's talk page should be ''moved'' there (thus preserving its history); if the redirect target's talk page already exists, any redirect's talk page discussions should be ''merged'' there. The redirect's talk page can then be either redirected to the target's talk page (automatic when moving), fixing any double redirects, or marked for deletion ([[Help:Style#Redirect pages|without redirecting]]), fixing any backlinks first. Do we want to enforce only one of these possibilities or leave the choice case by case?<br />
:Note that admins and maintainers have the ability to move a page without leaving a redirect (deleting the original title), which could be taken into consideration, of course still taking care of fixing any backlinks first.<br />
:Finally, this could be part of an old [[User:Kynikos/Tasks#Ideas|idea]] of mine to create a page with checklists/procedures for the most common operations on articles, but that would be another discussion :)<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:19, 22 August 2013 (UTC)<br />
<br />
::Sorry for the delay, I've been inactive for a while.<br />
::Clearly discussions that become irrelevant after the redirect (like [[Talk:Tint#Merge with Tint2]]) can be removed. There may be discussions that are still relevant after the redirect (e.g. content related issues, can't find any good example right now), these issues should preferably be solved before redirecting the page, but that's up to the editor. I agree that remaining discussions should be moved/merged to the talk page of redirect target, so the question is what to do with the blank talk page?<br />
::I understand that there may be external websites with links to talk pages on ArchWiki and deleting the old talk page instead of redirecting it is rather unfriendly. On the other hand, those links are not used very often, especially for talk pages of some outdated, unmaintained or not very important pages. Just deleting it is much simpler (eh, the redirect is simple consequence of ''moving'' the whole talk page, but when the target talk page exists, deleting the source is simpler).<br />
::I also think that the redirects (at least for talk pages) should be deleted after some time, just another cleanup step. Especially if the main page was redirected for the second time (e.g. to fix some double redirect), take [[Talk:Suspend to Disk]] as an example.<br />
::Generally I don't have anything against redirects, it just makes the maintenance more difficult. For talk pages I think they are mostly superfluous.<br />
::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:11, 26 August 2013 (UTC)<br />
<br />
:::One problem I see is that deleting a redirecting talk page will make the history of any merged discussions inaccessible to normal users. Anyway this could be trivial, and recommending to mark the talk page for deletion would leave the final choice to an admin, who is supposed to be able to judge what's best to do, also considering redirecting as a possibility. So I've added a procedure to [https://wiki.archlinux.org/index.php?title=Help%3AEditing&diff=272909&oldid=272907 Help:Editing], do you like it? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:04, 28 August 2013 (UTC)<br />
<br />
::::Looks good. An idea: [[Help:Editing#Redirects]] could be split into three subsections, 1) what is a redirect, 2) when to redirect a page, 3) how to redirect a page. This could be applicable also to other procedures from your [[User:Kynikos/Tasks#Ideas|ideas]] and probably deserves separate discussion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:52, 28 August 2013 (UTC)<br />
<br />
::::As I said earlier, I messed up a few talk pages when redirecting. I've now marked most of them for deletion, see [[User:Lahwaacz#Messed_up_by_redirecting_the_main_page]] for quick list. The last one in the list, [[Talk:Map Custom Device Entries with udev]], contains two open discussions - I doubt they are still relevant, but I'll have to investigate further. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:47, 28 August 2013 (UTC)<br />
<br />
== Distinguish fragment identifier interwiki links? ==<br />
<br />
Similarly to [[#Visited_links_color]], can we distinguish [[Wikipedia:Fragment identifier|fragment identifier]] interwiki links (those written as {{ic|<nowiki>[[#foo]]</nowiki>}}) from other interwiki links (generally pointing to some other page)? I find something like {{ic|<nowiki>[[#PolicyKit authorization|PolicyKit authorization]]</nowiki>}} [https://wiki.archlinux.org/index.php?title=Libvirt&diff=next&oldid=274533] kind of confusing, it should be clear that the link points to a section on current page and not to separate page. Possibilities:<br />
<br />
# prefer {{ic|<nowiki>[[#foo]]</nowiki>}} instead of {{ic|<nowiki>[[#foo|foo]]</nowiki>}} - this does not solve something like {{ic|<nowiki>[[#Run daemon|run the daemon]]</nowiki>}}, also note that the fragment is case-sensitive<br />
# add some icon (superscript?) in front of/behind the link, I was thinking about the arrow shown in [https://wiki.archlinux.org/index.php?title=Help_talk:Style&action=history history pages] (but without the link to the section)<br />
# use some other color<br />
<br />
I'd vote for the second, it seems to be the most universal. Or does anybody have some other suggestion?<br />
<br />
(Looking at the second link in this post, something similar could be done for links to Wikipedia. In this case, I propose adding superscript {{ic|W}} behind the link.)<br />
<br />
Sorry if this has already been discussed somewhere else, I don't have the time to search it right now.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 7 October 2013 (UTC)<br />
<br />
:Talking of distinguishing links, external https links are not distinguished either:<br />
::[http://foobar.org http]<br />
::[https://foobar.org https]<br />
:Perhaps a bug?<br />
: -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:10, 10 October 2013 (UTC)<br />
<br />
::About the little icons next to links, I guess we could do it easily with CSS attribute selectors in the skin files.<br />
::About the https icon in particular, it looks it was disabled on purpose for some reason: [https://projects.archlinux.org/vhosts/wiki.archlinux.org.git/tree/skins/archlinux/arch.css] (line 67) I'd be curious to know why.<br />
::Of course to implement all this, a bug report should be opened and very likely patches should be prepared, so if you think you have the time to work on it, the project is at [https://projects.archlinux.org/vhosts/wiki.archlinux.org.git/] with links to clone the repo. I'd be interested in giving a hand of course :)<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:53, 10 October 2013 (UTC)<br />
<br />
:::Thanks for pointing me to the right direction, here's the commit about the https links: [https://projects.archlinux.org/vhosts/wiki.archlinux.org.git/commit/skins/archlinux/archlinux.css?id=e8b7a08c663a0fb392a24c67ec1dea59057f480a].<br />
:::Let's see if I can get to this again this weekend...<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:05, 10 October 2013 (UTC)<br />
<br />
::::I sent an email to [[User:Pierre|Pierre]] about the commit in November and did not receive any reply, so I submitted a bug report: {{Bug|38769}} - hopefully it won't be missed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:00, 2 February 2014 (UTC)<br />
<br />
:::::We'll see, I've submitted a patch, but unfortunately wiki bugs, even if easy to fix, have a [https://bugs.archlinux.org/task/35545 long life]... -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:17, 3 February 2014 (UTC)<br />
<br />
== Problem with keyboard keys style ==<br />
<br />
I could use some help with [[Keyboard Shortcuts]]:<br />
<br />
<s>According to [[Help:Style#Keyboard_keys]], {{ic|Ctrl}}+{{ic|Alt}}+{{ic|+}} should be {{ic|Ctrl+Alt++}}, but is that clear enough? (see [[Keyboard_Shortcuts#X11]])</s><br />
<br />
Also, what would be the preferred style for showing multiple shortcuts for some modifier combination?:<br />
<br />
* {{ic|Alt}}+{{ic|.}}or{{ic|_}}<br />
* {{ic|Ctrl}}+{{ic|Alt}}+{{ic|+}}/{{ic|-}}<br />
* {{ic|Ctrl}}+{{ic|Alt}}+{{ic|F1}}, {{ic|F2}}, {{ic|F3}}, ...<br />
<br />
(note: someone used {{ic|&uArr; Shift}} on that page, the arrow looks really funny :D )<br />
<br />
'''Edit:''' the {{ic|Ctrl+Alt++}} shortcut was either dropped from X or is specific to NVIDIA, so I've [https://wiki.archlinux.org/index.php?title=Keyboard_Shortcuts&diff=288958&oldid=288082 removed it] from the list of standard shortcuts. The only references I found were about 6 years old, the original is probably [http://ubuntuforums.org/showthread.php?t=83973 this].<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:22, 16 December 2013 (UTC)<br />
<br />
:(I don't wanna know where you've downloaded the font you're using with your browser... XD )<br />
:Oh well, even though {{ic|Ctrl+Alt++}} was (luckily?) outdated in that context, that's certainly a big flaw in the style rule... What do we want to do, switch to the {{ic|Ctrl}}+{{ic|Alt}}+{{ic|+}} format? It would invalidate many of the style edits that have been done in the last months, but a bug is a bug ^^ Any better ideas?<br />
:About variable combinations, maybe we can just give some examples but leave the choice up to the editor?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:48, 17 December 2013 (UTC)<br />
<br />
::I would not change the rule for just one shortcut (resp. two: {{ic|Ctrl+Alt+-}}), converting it back would be really exhausting. If another instance appears, I'd create an exception for it. Or, even better, just link to an external documentation :P<br />
::Regarding the second problem I agree with leaving it up to the editor. Examples could be:<br />
::* press {{ic|Alt+.}} or {{ic|Alt+_}}<br />
::* press {{ic|Ctrl+Alt+F''N''}} to switch to the {{ic|''N''}}-th virtual console<br />
::i.e. basically use the full, expanded form or the [[Help:Style/Formatting_and_Punctuation#Pseudo-variables_in_file.2Fcommand_line_contents|pseudo-variables]].<br />
::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:12, 18 December 2013 (UTC)<br />
<br />
:::Well, let's just suspend this discussion until a similar problem is found again then, if ever. I'll think about closing it next time I'll come here to do some general clean up. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:25, 19 December 2013 (UTC)<br />
<br />
::::Putting spaces around the {{ic|+}} character would mitigate some of the confusion in the example Lahwaacz pointed out, but this would unfortunately require a lot of work to bring everything up to a new standard.<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:32, 11 January 2014 (UTC)<br />
<br />
:::::Um... {{ic|Ctrl + +}} doesn't look much clearer than {{ic|Ctrl++}} to me, if one day we'll need to change the rule for keys, we'll better do it the safest way, which probably is {{ic|Ctrl}}+{{ic|+}}, since as you point out it's going to be "a lot of work" in any case. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:51, 12 January 2014 (UTC)<br />
<br />
== Grammar errors throughout Help:Style ==<br />
<br />
I've found a large amount of grammar errors throughout [[Help:Style]], and it would be quite tedious to list a before and after for each one here in order to get them fixed. Would it be possible to either temporarily unlock [[Help:Style]] for editing (and closely monitor it for unauthorized changes), or if you don't want to unlock it for editing, should I just provide a pastebin with the revised wiki markup that you can copy/paste into the locked page? The downside to the latter option is that one really large change can be a pain to sort through in the history due to the lack of more verbose comments; although, if it's mostly simple grammar fixes, I guess this wouldn't be too big of a problem, as the change comments would likely be quite minimal.<br />
<br />
-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 03:41, 11 January 2014 (UTC)<br />
<br />
:It would be awesome if you could fix those errors, it will also be a good chance for me to improve my English: the article is unlocked now. Just make sure not to alter the explicit ''and'' implicit meaning of rules, e.g. [https://wiki.archlinux.org/index.php?title=Help:Style&diff=178056&oldid=178055] ;) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:16, 12 January 2014 (UTC)<br />
<br />
:I have a general question: what are the rules for using mdash ("&mdash;") vs. ndash ("&ndash;") in English literature? Is there supposed to be a space around them or not?<br />
:(I did not intend to challenge your work, I'm just curious - the rule is very likely to be different from those used in Czech...)<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:57, 11 February 2014 (UTC)<br />
<br />
::There is not supposed to be a ''full'' space around the em dash ("&mdash;") or the en dash ("&ndash;"). Ideally, the [https://en.wikipedia.org/wiki/Space_(punctuation)#Hair_spaces_around_dashes em and en dashes will be surrounded with a hair space], which is just wide enough to put a one pixel space between the dash and the adjacent characters, which makes it easier to read because the dash doesn't look like it's part of an adjacent character. I did not put hair spaces in my edits because I generally find it tedious to do.<br />
::As for when you should use the em dash vs. the en dash... the em dash is used for large pauses in speech or for side notes&#8202;&mdash;&#8202;notice the hair spaces around these em dashes&#8202;&mdash;&#8202;and the en dash is used for numeric ranges (e.g. 47&#8202;&ndash;&#8202;83).<br />
::The hyphen looks similar to the en dash (&nbsp;- &ndash;&nbsp;&nbsp;&larr; hyphen on the left, en dash on the right), but the hyphen is only supposed to be used between certain compound adjectives and nouns.<br />
::There's also the minus sign ("&minus;"), which looks very much like an en dash (&nbsp;&minus; &ndash;&nbsp;&nbsp;&larr; minus sign on the left, en dash on the right). It should only be used in mathematical formulas or when writing negative values (e.g. 47 &minus; 83 = &minus;36)<br />
::If you haven't noticed, I'm a bit of a typography geek. haha<br />
::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 02:02, 13 February 2014 (UTC)<br />
<br />
:::Thanks for this nice explanation! It is a shame that the wiki markup language does not have special syntax for this punctuation, entering the HTML codes is ''really'' PITA. There are some packages for LaTeX that translate "--" into en dash and "---" into em dash. But typographically, TeX is on completely different level than wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:08, 13 February 2014 (UTC)<br />
<br />
::::We could possibly add MediaWiki templates for the em dash and en dash. Adding a template for the minus sign seems like it might be overkill. For example, <nowiki>{{emdash}}</nowiki> or <nowiki>{{em dash}}</nowiki> would output {{ic|&.#8202;&.mdash;&.#8202;}} (without the dots, of course)<br />
::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 23:59, 18 February 2014 (UTC)<br />
<br />
:::::I say let's keep it simple, who would use those templates in practice? They would also go against our decision to e.g. use typewriter quotes instead of typographic, see [[Help:Style/Formatting_and_Punctuation#Quote_marks]]. As Lahwaacz mentioned, a wiki is not TeX, it's designed to keep source and rendered text similar, and punctuation templates would reduce readability of source text. MediaWiki takes care of translating source text characters into HTML entities when needed, and in my view we shouldn't try to bypass such feature except when really needed (see also [[Help:Template#HTML_entities]]). If you want to use some particular punctuation marks, IMHO you should enter them directly, possibly assigning them as special combinations to your keyboard map. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:00, 19 February 2014 (UTC)<br />
<br />
::::::Regarding source text readability, why not just input the unicode character itself — like this? (Notice that it works also for the hair spaces, though they are not very "hairy" in the source...) -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:01, 19 February 2014 (UTC)<br />
<br />
::::::I would use those templates. :)<br />
::::::I agree that <nowiki>{{em dash}}</nowiki> would be less readable than a directly-entered "—" character; however, <nowiki>{{em dash}}</nowiki> is a ''lot'' more readable than {{ic|&.#8202;&.mdash;&.#8202;}} (without the dots), which is why I support the idea. I feel that directly-entered em dashes with the surrounding hair spaces (using the Unicode characters directly) is less maintainable than <nowiki>{{em dash}}</nowiki> because subsequent edits may remove one or both of the hair spaces without editors realizing that they did so.<br />
::::::-- [[User:Jstjohn|Jstjohn]] ([[User talk:Jstjohn|talk]]) 01:14, 20 February 2014 (UTC)<br />
<br />
:::::::Ok, I admit that to me all this seems overly complicated as in not Simple, however, as [[Help:Style/Formatting_and_Punctuation#General_rules]] says, "for cases not covered in this guide, [[Wikipedia:Wikipedia:Manual of Style]] is the authority reference", and to me it seems very sensible to stick with that rule instead of attempting to create our own punctuation guides. In particular, [[Wikipedia:Wikipedia:Manual_of_Style#Punctuating_a_sentence_.28em_or_en_dashes.29]] says "do not use spaced em dashes", while they do have a <nowiki>{{spaced ndash}}</nowiki> template, so IMO that's what we should follow. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:21, 20 February 2014 (UTC)<br />
<br />
::::::::If we decide for the templates way, which subset of the [[Wikipedia:Category:Wikipedia_formatting_and_function_templates|Wikipedia formatting and function templates]] should be used on ArchWiki?<br />
::::::::I don't like the templates either, this had better be solved upstream (either directly in the parser core or via an extenasion. The only mention of upstream dealing with this I found is [https://meta.wikimedia.org/wiki/MediaWiki_feature_request_and_bug_report_discussion/Archive#.22Incorrect.22_quotes this] rather old discussion, so it's probably going nowhere. (Extending the parser should not be that hard, a couple of regular expressions should do it for the dashes -- I'm surprised that it's not done yet...)<br />
::::::::Suggestions so far: 1) use HTML entities (such as {{ic|&amp;mdash;}}), 2) use templates (such as {{ic|<nowiki>{{em dash}}</nowiki>}}), 3) use the Unicode characters directly, 4) use some extension (none found yet), 5) drop the typography rules completely (use plain spaced hyphen "{{ic| - }}" or commas) -- this could be called "wait for upstream to implement the necessary change" :P<br />
::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:43, 20 February 2014 (UTC)<br />
<br />
:::::::::Well, as I've said I'm for 3), with the possible advice of setting key combinations for the most frequent cases (e.g. {{ic|AltGr}} + {{ic|-}}<sup>I'm aware of [[#Problem_with_keyboard_keys_style|1]]</sup> for the em dash). Just out of curiosity, _personally_ I tend to use ~5) because in my native language all the cases where English requires dashes are covered by commas or parentheses, so I'll be seen rarely, if ever, using dashes in my contributions.<br />
:::::::::Even if there was an extension to parse "--" and "---", we'd still find resistance for having it installed in our wiki... Maybe upstream they're just waiting for your patch! ;)<br />
:::::::::About Wikipedia's "formatting and function" templates, for sure we're discarding the "function" ones, and about the others I'd say let's create them one at a time whenever one is needed, but only if method 3) and method 1), in that order, would require too much typing effort for that case.<br />
:::::::::For completeness' sake, there's also a suggestion 6) to use a (theoretical) external editor that turns "--" and "---" into proper dashes before sending the text to the server, and does the opposite when retrieving a page for editing.<br />
:::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:38, 21 February 2014 (UTC)<br />
<br />
:::::::::A little note, the Colemak layout already comes with en dash and em dash respectively preset to {{ic|AltGr+-}} and {{ic|AltGr+Shift+-}}. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:49, 10 June 2014 (UTC)<br />
<br />
== Rule suggestion: reference links ==<br />
<br />
First of all, sorry if there is already some similar rule about this, I don't know (yet) what I've forgotten since last year :/<br />
<br />
The suggestion:<br />
:"When adding troubleshooting sections to new problems, always add reference links into the article, whenever such links are available."<br />
<br />
(There is (at least) one implied meaning: "...and not just in the edit summary" :) )<br />
<br />
These links will be mostly links to our [https://bugs.archlinux.org/ bug tracker] or the [https://bbs.archlinux.org/ forums]. The rule should probably include some examples.<br />
<br />
The reason behind this is quite obvious: the users (and maintainers) will easily know if the problem is still valid or already fixed.<br />
<br />
Finally, some reference links for completeness: [https://wiki.archlinux.org/index.php?title=Chromium&diff=296005&oldid=295185], [https://wiki.archlinux.org/index.php?title=MPlayer&diff=296894&oldid=296809]<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:48, 11 February 2014 (UTC)<br />
<br />
:The style guide should be currently freely editable, even though discussing any changes beforehand is a ''must'' (so thank you for doing it). You can go ahead and add a few examples, with the only recommendation to be as synthetic as possible, in accordance with the rest of the guide. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:09, 12 February 2014 (UTC)<br />
<br />
== Slashes in titles ==<br />
<br />
It should be made clear that {{ic|/}} in page titles will create a subpage, even if the parent page does not exist. Different wording (which ''must'' exist) should be used in cases where the subpage is not desired. While everything is working OK on the web interface, missing this detail will make alternative interfaces, e.g. {{Pkg|arch-wiki-docs}}, quite confusing.<br />
<br />
Some infamous pages suffering from this issue:<br />
<br />
* [[:Category:Audio/Video]]<br />
* [https://wiki.archlinux.org/index.php//dev/shm /dev/shm] (no idea why [[/dev/shm]] does not work here, it does in [[XFCE simple Network Monitor applet#Prerequisites]])<br />
<br />
Additionally, I don't like the use of {{ic|/}} even in section titles, it just looks wrong: [https://wiki.archlinux.org/index.php?title=List_of_applications&oldid=301902#Scans.2FImage List of applications#Scans/Image].<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:42, 21 March 2014 (UTC)<br />
<br />
:Umm, technically what I just said is wrong - subpages are disabled in the Main namespace. See for yourself: add {{ic|<nowiki>{{SUBPAGENAME}}</nowiki>}} to [[systemd/User]] and preview, it will return "systemd/User" and not "User". (Also notice the small navigation link below the title in [[Help:Style/Formatting_and_punctuation]]) [[mw:Manual:$wgNamespacesWithSubpages|$wgNamespacesWithSubpages]] is probably set to default value in Arch Wiki configuration.<br />
:See also [[wikipedia:Help:Subpages#Slashes_in_article_titles]].<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:56, 22 March 2014 (UTC)<br />
<br />
::Yes, subpages are disabled in the Main namespace. [[:/dev/shm]] works in [[XFCE simple Network Monitor applet]] because that article is in the Main namespace and slashes are not specially interpreted there, while they are interpreted as relative (to the current page) links in the other namespaces like Help_talk, hence the red link since [[Help_talk:Style/dev]] doesn't exist. You must prefix a link like that with a colon in order to turn it into an "absolute" link, like {{ic|<nowiki>[[:/dev/shm]]</nowiki>}}.<br />
::That said, do you still support mentioning subpages in the guide? And how exactly? Also, would you forbid slashes in section titles? (I wouldn't, but I'm open for discussing as always)<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:11, 22 March 2014 (UTC)<br />
<br />
:::Well, we should either enable subpages ''everywhere'' (or just the Main namespace in addition to those currently enabled?), or avoid using the term "subpage" altogether: [[Help:Style#Title]], [[Help:Style#Kernel module operations]], ..., [[Talk:Arch systemd container]], [[Talk:Dm-crypt]], ... Is there too much harm in having [[S/KEY Authentication]] a subpage of [[S]]? Is there a way to disable the 'subpage' feature on specific articles? Alternatively, would it be even more confusing to rename the page to [[S KEY Authentication]]?<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:32, 23 March 2014 (UTC)<br />
<br />
::::I tend to be against real subpages in the Main namespace, as they would prevent the normal usage of slashes in titles, as you note too. Wikipedia has the same configuration by the way (but http://wiki.gentoo.org uses subpages).<br />
::::I understand that using the term "subpage" can be confusing if taken literally, but how would you call the practice of naming articles like "Beginners' guide/*", "List of applications/*" and so on?<br />
::::[[S/KEY Authentication]] as a subpage of [[S]] would create a confusing link at the top of the page, under the title (IMHO more confusing than the current usage of the "subpage" term).<br />
::::If there was a way to disable subpages per-page, it would be through [[mw:Help:Magic_words]], but it looks like there's nothing for that (yet?).<br />
::::Renaming articles like [[S KEY Authentication]] would mean enforcing the rule of avoiding slashes in titles, which is something I would be against... Unless we make use of DISPLAYTITLE to display the correct titles?<br />
::::Finally, I refuse to open a report to change the configuration of the wiki before {{Bug|35545}} is implemented >:( (Please, anybody reading here, vote for it)<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 21:54, 23 March 2014 (UTC)<br />
<br />
:::::Interesting, [http://wiki.gentoo.org/wiki/Boost/How_build_systems_find_boost] does not show the link below the title. Maybe because the parent page does not exist? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:51, 23 March 2014 (UTC)<br />
<br />
::::::Very interesting indeed, I've done a test here and the link does not appear if the super-page doesn't exist. This actually turns my preference towards enabling subpages also in the Main namespace. However we should patch LocalSettings.php for that, and {{Bug|35545}} is a blocker unfortunately. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 18:21, 24 March 2014 (UTC)<br />
<br />
:::::::I have misunderstood [[metawikipedia:Help:Link#Subpage_feature|Meta-Wiki]] entry yesterday; today I found the information in [[mw:Help:Link#Subpage_feature|MediaWiki]] too, but Meta-Wiki adds an interesting detail about breaking the breadcrumb links sequence on first non-existent page.<br />
:::::::[[Wikipedia:Help:Subpages#History_of_subpages|Wikipedia]] describes that they originally used subpages, but then switched to the disambiguation system, which probably lead to disabling subpages by default. We don't use disambiguations, so I don't see any further reason why the Main namespace should behave differently.<br />
:::::::{{Bug|35545}} is the blocker, but we won't get anywhere without submitting another bug - it could be the necessary catalyst. (About [https://wiki.archlinux.org/index.php?title=User:Kynikos&diff=306809&oldid=286042]: you've won two votes since yesterday :)<br />
:::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:31, 24 March 2014 (UTC)<br />
<br />
::::::::You're absolutely right, I'll let you open the report since the idea and the research are yours; it would be better if you could restate the supporting arguments there instead of linking here, and finally emphasize the fact that a patch will be provided if {{Bug|35545}} is implemented first (if we manage to have it fixed, it will be very very useful in the future).<br />
::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 18:08, 26 March 2014 (UTC)<br />
<br />
:::::::::Reported in {{Bug|39668}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 00:03, 29 March 2014 (UTC)<br />
<br />
::::::::::Added my vote. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:30, 30 March 2014 (UTC)<br />
<br />
=== Localized subpages ===<br />
<br />
If {{Bug|39668}} is implemented, we should probably rethink the rule for localized subpages in [[Help:I18n#Article_titles]]. The problem is that with {{ic|Title/Sub-page (Language)}} the breadcrumb links below the title will point to the English page instead of the localized one. {{ic|Title (Language)/Sub-page}} makes more sense wrt file system hierarchy anyway, so I would do it anyway. Alternatively we may go the [[Help_talk:I18n#Language_namespace.28s.29_in_place_of_suffixes.3F|language namespaces]] way, which should also solve this problem. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:30, 4 April 2014 (UTC)<br />
<br />
:My original intention behind the {{ic|Title/Sub-page (Language)}} style was to make it safer for [[Wiki Monkey]] to detect the language of an article by just looking at the end of the title, but I guess I might as well look for the tag anywhere in the title, and realistically it wouldn't give any troubles, so when {{Bug|39668}} is implemented we can indeed change the rule and rename the affected articles. The [[Help_talk:I18n#Language_namespace.28s.29_in_place_of_suffixes.3F|language namespaces]] way is still my long-term-preferred solution though. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 01:40, 5 April 2014 (UTC)<br />
<br />
== Formatting of references to man pages ==<br />
<br />
''[Moved from [[Help talk:Style/Formatting and punctuation#Formatting of references to man pages]] -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:24, 29 June 2014 (UTC)]''<br />
<br />
How should references to manpages be formatted? Possible formats:<br />
# {{ic|pacman}}(8)<br />
# {{ic|pacman(8)}}<br />
# ''pacman(8)''<br />
# .....see ''pacman'' manual.....<br />
#:or even maybe<br />
# {{ic|man 8 pacman}}<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:53, 28 June 2014 (UTC)<br />
<br />
:Ok, let's standardize this, I think the clearest is "... see {{ic|man pacman}} for details ...": the formatting complies with [[Help:Style/Formatting and Punctuation#CLI lines]] where it's already used as an example. I would leave the section number optional, it's quite rare that the same name is in two different sections, so we can recommend to specify it only in cases of ambiguity.<br />
:Let's read more opinions. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:34, 29 June 2014 (UTC)<br />
<br />
::I am ok with {{ic|man pacman}}.<br />
::Pros:<br />
::* Newbies who haven't encountered manpages yet (which I think is rare) can simply run the command and not wonder what pacman(8) is.<br />
::Cons:<br />
::* It implies that manpages should be read via {{ic|man}}. There are some great alternatives out there or may appear in the future. Of course users of these alternatives can run the equivalent command, but still.<br />
::Other thoughts: For popular manpage it's not very rare when one with same name is in different sections (crontab, man, intro, kill, link, locale, passwd, time, write, hostname). When a section isn't specified, this is the search priority:<br />
::* 1 or 8 - executables or system executables<br />
::* 3 - library calls<br />
::* 2 - kernel calls<br />
::* 5 - file formats<br />
::* 4 - special files (/dev)<br />
::* 6 - games<br />
::* 7 - misc<br />
::So we should be a bit careful when not specifying the section number. Though this shouldn't be a problem as the author has probably ran the command himself and means the first one in the priority list.<br />
::EDIT: If the user is using one of the alternative viewers and section number isn't specified, that can cause problems for multi-section pages. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 07:08, 29 June 2014 (UTC)<br />
<br />
:::It is good to consider users with alternative viewers as you do, but using one is an explicit choice. Hence, it seems fair to imply the user knows how to use it as a {{ic|man}} replacement. From the alternatives referencing the section in brackets only those having the section bracket outside the {{ic|ic tag}} would be workable. However, we generally want to give the man reference prominence and for that a "see {{ic|man passwd}} for options" is more prominent than a "see passwd(1) for options". That said, I'd personally like the non-ic version because it is a better textflow in my view. Plus the prominence the ic-tag gives is watered down the more it is used for peripheral commands. <br />
:::For the reason you give regarding the author (the editor deciding whether {{ic|man 5 passwd}} or {{ic|man 1 passwd}} is referenced) it seems safe to leave it optional like Kynikos suggests. <br />
:::To add another thought: In special cases it may even be helpful to reference it externally, e.g. like [http://linux.die.net/man/5/passwd passwd's manpage], particularly when it can be assumed the user has no access to it yet on the system itself. For example: we frequently have man references in the article preface, but referencing a package's man page at that early point (before the installation section) is not particularly reader friendly. The problem with external links is of course consistency, i.e. there are too many outdated external references. But most editors are well aware of that, I'd say. <br />
:::So, with the exception of special cases, I am +1 to Kynikos' suggestion if a rule is made, but like to add that I don't feel a need for it to be standardised. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:44, 29 June 2014 (UTC)<br />
<br />
::::Good point Indigo, we can't assume the manpage's package is installed. I'd say we can allow two versions of references to manpages:<br />
::::* If the package is probably not installed, use "see ''pacman'''s [https://www.archlinux.org/pacman/pacman.8.html manual] for details" with the recommendation to prefer linking to the official web representation of the manpage, if available.<br />
::::* If the package is probably installed, use "see {{ic|man 8 pacman}} for details", with the possibility to omit the section number when not ambiguous.<br />
::::* If the manpage is linked in a See also section, use the normal See also style instead (discussed in [[#Manpages in "See also" sections]]).<br />
::::Do you like it? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:19, 30 June 2014 (UTC)<br />
<br />
:::::Oh, fine with me. Thanks for working it out. I particularly like the recommendation towards referencing official package's web manpages too; very beneficial for content overall & software rolling forward. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:14, 30 June 2014 (UTC)<br />
<br />
::::::[https://wiki.archlinux.org/index.php?title=Mount&diff=330649&oldid=330646 This] is one of the reasons why external links for man pages can be harmful - some distributions may provide patched packages including patched man pages. As Arch provides mostly vanilla packages, the link should lead to upstream's page, which should be the most up to date version (also third-party sites may become outdated after some time). Perhaps this should be mentioned as well. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:59, 16 August 2014 (UTC)<br />
<br />
== Lists, colons, indentation ==<br />
<br />
As a continuation of [https://wiki.archlinux.org/index.php?title=Help_talk:Style&oldid=316593#Block_quotations Block quotations], let's clarify our position to multi-line blocks inside lists and indentation (definition lists without definition terms). I have slightly mentioned this in the previous discussion, and I'd like to finish it here.<br />
<br />
The markup lists are designed to be simple, and apparently are unsuitable for more complex lists, e.g. with multi-line blocks inside. [[wikipedia:Wikipedia:Manual_of_Style/Lists#Bulleted_and_numbered_lists|Wikipedia says]]: "Do not use lists if a passage is read easily as plain paragraphs." I think that most of the "incorrectness" on Arch wiki comes from disobeying this quote. We should probably recommend using the lists only in simple cases, one or two paragraphs in each item at most (use &lt;br> tags to separate them).<br />
<br />
Other common case, unfortunately falling into the non-simple category regarding markup, is that a [[template:note|note]] or [[template:tip|tip]] is presented inside a list. The "common" syntax has been<br />
{{bc|<nowiki><br />
* some text<br />
: {{Note|text to note}}<br />
</nowiki>}}<br />
but I've recently seen a number of edits changing it to<br />
{{bc|<nowiki>* some text {{Note|text to note}}</nowiki>}}<br />
which is something I don't like, because even though the latter renders correct HTML, it makes the wikitext unreadable. As much as we don't like it, definition lists without definition terms are a ''feature'', and the [[mw:Help:Lists|MediaWiki's manual]] is full of such tricks. To achieve a fully correct HTML output only with markup syntax, we would need to fix the parser/renderer anyway, so I think we should focus more on wikitext readability.<br />
<br />
The only way to achieve correct HTML, is to use HTML tags in wikitext, which brings me to the next problem: [https://wiki.archlinux.org/index.php?title=QEMU&diff=next&oldid=321689]. The edit clearly breaks the (future) rule "Do not use lists if a passage is read easily as plain paragraphs.", so the problem is reduced to usage of manual numbering - is it acceptable or do we tolerate HTML tags in such cases?<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:11, 29 June 2014 (UTC)<br />
<br />
:I agree, look at [https://wiki.archlinux.org/index.php?title=Compiz_%28Espa%C3%B1ol%29&oldid=273960 this page broken by a "Translateme" template inside a list]. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 08:30, 29 June 2014 (UTC)<br />
<br />
::I've used the {{ic|<nowiki>* some text {{Note|text to note}}</nowiki>}} trick several times myself, but after reading Lahwaacz's reasoning I won't anymore <small><small>(when I'll remember)</small></small>, as I agree completely: we should aim for the ''cleanest'' source text that results in the ''wanted'' appearance of the page. If the generated HTML is not correct it's indeed a problem of MediaWiki, we shouldn't try to work around it.<br />
::Yes, we should encourage preferring paragraphs or even subsections to lists with long/complex items. About ordered lists, manual numbering looks quite ugly to me, and I feel the same about mixing HTML and wiki markup: I think most (hopefully all) of the cases where it would be needed are better solved in some other way. For example in the QEMU case reported above, the items of that list don't need to be numbered, bullets or subsections should be used. Another notable example is [[Arch_packaging_standards#Submitting_packages_to_the_AUR]], where bullet points would be more appropriate.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:49, 30 June 2014 (UTC)<br />
<br />
:Maybe we can create a template for items? I mean something like this:<br />
:{{bc|<nowiki>* First item<br />
* Second item<br />
* {{Template_name|<br />
Third item<br />
<br />
{{Note|bla-bla}}<br />
<br />
Bla-bla-bla<br />
}}<br />
*Fourth item<br />
</nowiki>}}<br />
:And there will be a good readability of wikitext as well as correct indentations<br />
:-- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 07:47, 4 July 2014 (UTC)<br />
<br />
::This still seems too complicated to me. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:15, 5 July 2014 (UTC)<br />
<br />
::I don't think such template is possible, the blank lines would still break the list (test it for [[Template:bc]] without &lt;nowiki> tags). All the templates for lists on Wikipedia work the other way, template arguments are turned into list items. See for example [[wikipedia:Template:Ordered list]], but it relies on [[mw:Extension:Scribunto|Lua scripting]], which is not available on Arch wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:42, 5 July 2014 (UTC)<br />
<br />
== See also links ==<br />
<br />
This is a low priority discussion, more of a reminder, however I'd like to recommend a unified style for external links in See also sections, because at the moment the various articles are inconsistent about that. These are some options:<br />
<br />
* [https://www.archlinux.org/ Arch Linux home page]<br />
* Arch Linux home page: https://www.archlinux.org/<br />
* Arch Linux home page — https://www.archlinux.org/<br />
* https://www.archlinux.org/ — Arch Linux home page<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:36, 1 July 2014 (UTC)<br />
<br />
:I vote for the first style. It's compact and IIRC already more popular than the other styles. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:00, 1 July 2014 (UTC)<br />
<br />
::Agreed with axper, +1 to the first style. --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:28, 1 July 2014 (UTC)<br />
<br />
:::I like the first style too. Also, I think this is how the Wikipedia does it. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 20:35, 1 July 2014 (UTC)<br />
<br />
::::I'd prefer the first style too, but I forgot that links in See also section can be accompanied by descriptions, these are some examples of how the style can vary: [[Core utilities#See also]], [[Secure Shell#See also]], [[Systemd#See also]], [[KDE#See also]] (funny), [[Xfce#See also]], [[List of applications#See also]]. I haven't made up my mind yet. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:48, 5 July 2014 (UTC)<br />
<br />
::::Meahwhile I've run into a non-standard section in [[Cursor Themes]] and I've changed it [https://wiki.archlinux.org/index.php?title=Cursor_Themes&diff=323541&oldid=323304 like this]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:01, 6 July 2014 (UTC)<br />
<br />
:::::+1 for the first style. Yet the examples show how useful a description can be, I vote for making it optional. Having an optional description behind the link looks much neater as well imo, rather than trying to use the link title to transport it in those cases. <br />
:::::Focussing on the links in [[Systemd#See also]]: some are indeed a little dated (already), but it would be a pity to loose them. I was wondering for a moment whether it would make sense to foster grouping them, e.g. <br />
::::::* systemd tips and tricks: <br />
::::::** [http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions systemd FAQ]<br />
::::::** [http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks systemd tips and tricks]<br />
::::::** [http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]<br />
::::::* systemd project information: <br />
::::::** [http://0pointer.de/blog/projects/systemd.html Lennart's blog story] - on the motivation to create systemd <br />
::::::** ...<br />
::::::** [http://0pointer.de/blog/projects/systemd-update-3.html systemd status update 3] — (April 2012)<br />
:::::But then again there are few cases with that many links and the description can be useful/enough to transport that information too. Some sort of grouping happens automatically by editors keeping relevant links together and ordering most relevant (e.g. project home pages) first. <br />
:::::In my view the whole could be clarified by just appending some examples to [[Help:Style#.22See_also.22_sections]] ala: <br />
::::::Examples: <br />
::::::* [https://www.archlinux.org/ Arch Linux home page]<br />
::::::* [http://www.x.org/releases/current/doc/man/man3/Xcursor.3.xhtml man Xcursor] — for more information about cursors in X (supported directories, formats, compatibility, etc.).<br />
::::::* [http://0pointer.de/blog/projects/systemd-update-3.html systemd status update 3] — (April 2012)<br />
:::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:28, 11 August 2014 (UTC)<br />
<br />
== Preferred subpage method ==<br />
<br />
Options:<br />
<br />
* Page/subpage (examples: [[Perl Background Rotation/Tips]], [[List of applications/Utilities]])<br />
* Page - subpage (ex: [[Btrfs - Tips and tricks]]<br />
* Page subpage (ex: [[GNOME tips]], [[pacman tips]])<br />
* No subpages (using sections instead)<br />
<br />
See also: [[#Slashes_in_titles]] --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:16, 2 July 2014 (UTC)<br />
<br />
:I think, current method (number one) is good. The third one is bad (for example, it's very bad for ''List of applications Utilities''). You can add another method with colon symbol: ''Page:subpage''. But I'm ok with the first one -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 07:56, 4 July 2014 (UTC)<br />
<br />
::As [[mw:Help:Subpages|subpages]] are a feature of MediaWiki, the ''only'' way to have a full subpage experience is the first option. Unfortunately, it is currently disabled in the ''Main:'' namespace on Arch wiki (see [[#Slashes in titles]]). Until it is enabled, all options have equal weight, but using anything different than slashes does not make sense if we want to eventually switch to them. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:20, 4 July 2014 (UTC)<br />
<br />
:::As Lahwaacz says, using the slash form is the way to go for forward compatibility, do we want to write a rule and already start changing the existing non-compliant titles (e.g. [[pacman tips]])? The problem is that without the little navigation links under the title, it's not immediate to understand the meaning of the slash, especially for short titles, which at the moment look neater with a simple space. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:59, 5 July 2014 (UTC)<br />
<br />
::::My vote goes for option #4 (using sections like Wikipedia):<br />
::::# Doesn't to pollute the "Related articles" column with number_of_subpages<sup>2</sup> lines (or equivalent) with added complexity of maintaining all that<br />
::::# Doesn't pollute the category pages<br />
::::# It's easier to find information (i.e. {{ic|Ctrl+f}} or {{ic|/}} or by looking at TOC)<br />
::::# No confusion caused by non-existent separator character<br />
::::# Is just simple. Remember KISS? :)<br />
::::[[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:08, 8 July 2014 (UTC)<br />
<br />
:::::OK, let's compare us to Wikipedia (see [[wikipedia:Wikipedia:Subpages]] for reference). Basically, it forbids using subpages in the ''Main:'' namespace. The history section states, that subpages were once used to create hierarchies of articles, but then it was superseded by categories and disambiguations. On Arch wiki, the hierarchy of categories was designed as a ''tree'' (although in practice with some "converging branches", see [https://wiki.archlinux.org/index.php?title=Help_talk:Style&oldid=324150#Category_pages_-_tree_or_otherwise.3F #Category pages - tree or otherwise?]) and we don't use disambiguations at all. Unlike Wikipedia, so far this system works quite well on Arch wiki, which I think is mainly due to the type of content, amount of content and greater devotion and attention to detail of the [[ArchWiki:Maintenance Team|Maintenance Team]] :)<br />
:::::Sometimes an article is too long to be kept on just one page, and the easiest solution is to split some ''section'' into a separate article, which will effectively create a ''subpage''. I don't really see how this could be avoided without completely rewriting it, disambiguations or categories won't help here.<br />
:::::But I could agree that the usage of subpages should be regulated, for example [[PulseAudio/Troubleshooting]] would be good, while [[Kernels/Compilation/Traditional]] would be wrong (see the Wikipedia case). I don't know yet about [[Color Bash Prompt]] and something like [[Bash/Color prompt]].<br />
:::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:00, 9 July 2014 (UTC)<br />
<br />
::::::Well, solution #4 would be ideal, but in practice I think we can't really help splitting articles, both for length issues and because it's hard to understand when to stop merging articles back to their "parents". Take for example [[dm-crypt]]: it has several quite long subpages, would an article that merges all of them be clearer to read? I wouldn't see it as an improvement. And then why not merge [[dm-crypt]] and the others back to [[Disk encryption]]?<br />
::::::A subpage system is much more manageable, especially from the point of view of the maintainers, rather than the readers, so we just have to stick with it and make it as efficient and organized as possible.<br />
::::::@Lahwaacz How would you rename [[Kernels/Compilation/Traditional]]? [[Kernels/Compilation]] is the only child of [[Kernels]] (and currently only a redirect), so probably all those [https://wiki.archlinux.org/index.php?title=Special%3APrefixIndex&prefix=Kernels%2F&namespace=0 subpages] could be moved to [[Kernels/Traditional compilation]] and so on. Maybe we could limit the depth of subpages to just 1 in general?<br />
::::::About [[Color Bash Prompt]], I think its natural subpage version would be more [[Bash/Prompt color]], or, considering the actual content of the article, [[Bash/Prompt customization]] (I think we're using the AE spelling everywhere, but that's something else that's not regulated yet), [[Bash/Prompt style]] or similar.<br />
::::::-- 09:57, 10 July 2014 (UTC)<br />
<br />
:::::::Yes, [[Kernels/Traditional compilation]] looks good. About [[Color Bash Prompt]], I think that "color" is either a verb (as in "colorize") or an adjective, so I used it the same. But your alternatives are better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:21, 10 July 2014 (UTC)<br />
<br />
::::::::Thanks, what about limiting the depth of subpages to 1? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:13, 12 July 2014 (UTC)<br />
<br />
:::::::::I wouldn't mind more levels, provided that the first/previous level is wide enough. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:49, 12 July 2014 (UTC)<br />
<br />
== OK to put category pages in related articles list? ==<br />
<br />
Recently I made some edits which replaced links to multiple articles with a single link to a category page. That category page contains all those articles.<br />
* [[:Category:Hypervisors]]<br />
* [[:Category:Network managers]]<br />
<br />
Are people OK with this? If so, maybe edit [[Help:Style#Related_articles_box]] here to instead say:<br />
<br />
{{Box||<br />
* Provides a simple list of related internal pages.<br />
* Optionally included right below categories (or interlanguage links, or Article status templates, if present).<br />
* It can only be made of [[Template:Related articles start]], [[Template:Related]] and [[Template:Related articles end]]. See also the guidelines in those pages.<br />
* Non-English pages can make use of [[Template:Related2]] for translating the anchor text.<br />
* Use the [[#"See also" sections|"See also" section]] for a more complete and detailed list that also includes link descriptions and interwiki or external links.<br />
}}<br />
<br />
(change the word "article" to "page")<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 16:33, 10 July 2014 (UTC)<br />
<br />
:My first thought when reading this was "when the article is not included in the given category and it is still relevant, it should be included, otherwise not". On second thought, if the category is relevant enough, the article can be simple put into that category. The big problem is that related articles are at the top and related categories at the bottom.<br />
:We can either 1) leave pages at the top and categories at the bottom, 2) include every category into the 'Related articles' box at the top, 3) move the list of categories to the top (how?), 4) move the 'Related articles' box to the bottom (merge into 'See also' again).<br />
:Yep, so far I don't like either one of them for some reason or another...<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:25, 10 July 2014 (UTC)<br />
<br />
::About axper's proposed amendment, I agree, if a group of articles don't have a generic overview (e.g. unlike [[window managers]]), then linking to the category that groups them can be useful, if the edited article is not part of such category. Of course if the article itself is part of the category, there's the problem of duplicating the category link in the source text. This reminds me of an old idea of mine that I explained in [https://wiki.archlinux.org/index.php?title=Help_talk:Style/Article_summary_templates&oldid=287617#A_crazy_idea_.28about_Summary_templates.2C_Overview_templates_and_categories.29]: translated to the "modern" wiki, it could mean replacing the normal categorization system with a [[Template:Category]] to be added to the Related articles box, when present, so that the article gets categorized under some categories, but their links are also shown somehow in the floated box. For example:<br />
{{hc|Current system|<nowiki><br />
[[Category:Foo]]<br />
[[Category:Bar]]<br />
{{Related articles start}}<br />
{{Related|link}}<br />
{{Related articles end}}<br />
<br />
Body<br />
</nowiki>}}<br />
<br />
{{hc|New system|<nowiki><br />
{{Related articles start}}<br />
{{Category|Foo}}<br />
{{Category|Bar}}<br />
{{Related|link}}<br />
{{Related articles end}}<br />
<br />
Body<br />
</nowiki>}}<br />
<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:33, 12 July 2014 (UTC)<br />
<br />
:::The problem is that it involves more writing when there are no related articles (it is necessary to add <nowiki>{{Related articles start}}</nowiki> and <nowiki>{{Related articles end}}</nowiki> around the cats). Or would we use the current system for such pages? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:40, 12 July 2014 (UTC)<br />
<br />
::::I was just brainstorming, I'm not sure, maybe we could start using the RA box on every article? [[Wiki Monkey]] should have all the libraries needed to automate the migration, both for articles with an RA box and for those without, so the "extra writing" disadvantage wouldn't really apply. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:24, 13 July 2014 (UTC)<br />
<br />
== Convention on added/removed text in Hc Templates ==<br />
<br />
I just [https://wiki.archlinux.org/index.php?title=Nautilus&diff=prev&oldid=324433 used] the following way to clarify removed/added text in [[Nautilus#Use delete key to move to trash in Nautilus 3.6 and above]]:<br />
<br />
{{hc|~/.config/nautilus/accels|<br />
''<s>; (gtk_accel_path "<Actions>/DirViewActions/Trash" "<Primary>Delete")</s>''<br />
(gtk_accel_path "<Actions>/DirViewActions/Trash" "Delete")<br />
}}<br />
<br />
Is there already a policy on this? --'''<span style="text-shadow:grey 0.1em 0.1em 0.1em; font-size:110%">[[User:Det|<span style="color:gold">D</span><span style="color:orange">e</span><span style="color:red">t</span>]][[User talk:Det|<sup><font color="white">talk</font></sup>]]</span>''' 23:29, 10 July 2014 (UTC)<br />
<br />
:Nope, there's no policy on that (yet?). Your version is certainly an improvement, compared to the previous {{ic|-+}} system, although in my opinion there's no need to add italic to the stricken line (keep it simple). What I think I've seen around more often, though, is a more verbose:<br />
<br />
::In {{ic|~/.config/nautilus/accels}}, replace:<br />
::{{bc|; (gtk_accel_path "<Actions>/DirViewActions/Trash" "<Primary>Delete")}}<br />
::with:<br />
::{{bc|(gtk_accel_path "<Actions>/DirViewActions/Trash" "Delete")}}<br />
<br />
:Your version has the advantage of using [[Template:hc]], thus making it ''visually'' clearer that those lines are two versions of the same line, and belong to the same file. The "verbose" version has the advantage of giving clearer ''written'' instructions about what has to be done.<br />
:Replacing lines doesn't seem to be very frequent in articles, maybe standardizing this would be too much. If we decided to use the "stricken" version, it would probably be worth adding a note in [[Help:Reading#Append, create, edit and source]].<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:30, 11 July 2014 (UTC)<br />
<br />
== Links to redirects ==<br />
<br />
I'd like to recommend avoiding links like {{ic|<nowiki>[[Xorg#Composite|AIGLX]]</nowiki>}} or {{ic|<nowiki>[[daemons|daemon]]</nowiki>}} and promote linking to redirects, e.g. {{ic|<nowiki>[[AIGLX]]</nowiki>}} or {{ic|<nowiki>[[daemon]]</nowiki>}}: this would have the advantage of:<br />
<br />
# making the source text simpler and easier to read<br />
# keeping track of the particular "reason" why a link is made, also grouping the various links by "reason" in WhatLinksHere pages<br />
# allowing quickly updating link fragments in case of section renames<br />
<br />
We may even encourage to create redirects like those when the alternative text could be used somewhere else.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:09, 12 July 2014 (UTC)<br />
<br />
:Exactly my thoughts, we've gotten too far in the "update link(s) (avoid redirect)" series of edits, which apparently set a bad example for others. Redirects are a feature and as such should not be avoided, except for the following cases (which I consider confusing):<br />
:# the titles differ only in capitalization<br />
:# the link is given in the 'Related articles' floating box<br />
:# two links to the same target are given next to each other, one of them goes over redirect<br />
:Also when a phrase {{ic|<nowiki>See [[Some page]] for details.</nowiki>}} is used, it should be a direct link, but this is not very confusing and likely depends on context, sometimes redirects might be desired even in this case.<br />
:There are also some tricks to save writing the anchor text in some cases, see for example [[Help:Editing#Pipe trick]]. Then there is the following syntax: {{ic|<nowiki>[[window manager]]s</nowiki>}}, which will result in [[window manager]]s, but this can be solved also with a redirect. (off-topic: does [[Wiki Monkey]] support this?)<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:21, 12 July 2014 (UTC)<br />
<br />
::I agree with the exceptions. About {{ic|<nowiki>See [[Some page]] for details.</nowiki>}}, I'd still consider my points 2) and 3), and maybe at least don't explicitly list the case among the exceptions (we'll have to write this rule more as a recommendation than an obligation anyway, so the editors will be able to decide case by case). We could also recommend the pipe or the suffix trick over redirects when it's possible to use them. (OT: nope, [https://github.com/kynikos/wiki-monkey/issues/186 #186] [https://github.com/kynikos/wiki-monkey/issues/188 #188]) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:21, 13 July 2014 (UTC)<br />
<br />
== Titles: singular or plural? ==<br />
<br />
Currently we have [[daemons]], [[List of applications]], [[:Category:Proxy servers]]... but also [[window manager]], [[display manager]], [[:Category:Mail Server]]... I'm for enforcing the plural version in all cases. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:26, 13 July 2014 (UTC)<br />
<br />
:I agree, plurals sound better, it's also how Wikipedia does it:<br />
:* [[Wikipedia:Wikipedia:Naming_conventions_(plurals)#Exceptions]]<br />
:* [[Wikipedia:Wikipedia:Category_names#General_conventions]]<br />
:[[User:Axper|axper]] ([[User talk:Axper|talk]]) 07:35, 13 July 2014 (UTC)<br />
<br />
== Questionable edits ==<br />
<br />
There are several kinds of questionable edits made almost regularly to the wiki. They are '''not''' breaking any rules (yet?), I just find them useless, counter-productive, or even annoying. I'd like to discuss them to see how others feel. Of course feel free to add a section of your own. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
=== Underscores vs. slashes in kernel module names ===<br />
<br />
Example: [https://wiki.archlinux.org/index.php?title=USB_storage_devices&diff=next&oldid=328933] vs. [https://wiki.archlinux.org/index.php?title=Advanced_Linux_Sound_Architecture&diff=311976&oldid=310951]<br />
<br />
From {{ic|modprobe(8)}}: ''"there is no difference between _ and - in module names (automatic underscore conversion is performed)"''. Not only the naming is inconsistent across the wiki, this could lead to edit wars.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:Let's just pick one style and go with it. I vote for undescores, since that's how {{ic|lsmod}} prints them, consistency would be nice.<br />
:I wouldn't consider these 2 edits questionable, rather it's lack of [[Help:Style]] rules about this particular subject.<br />
:[[User:Axper|axper]] ([[User talk:Axper|talk]]) 06:04, 10 August 2014 (UTC)<br />
<br />
::+1 for regulating this with underscores as per axper's lsmod argument. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
=== <s>Versioned links</s> ===<br />
<br />
Examples: [https://wiki.archlinux.org/index.php?title=USB_Flash_Installation_Media&diff=prev&oldid=323158], [https://wiki.archlinux.org/index.php?title=USB_Flash_Installation_Media&diff=prev&oldid=328011]<br />
<br />
I don't mind anybody updating the values, I just cannot understand why would someone update ''all'' of them regularly. It should be expected that these values will be outdated soon, the wording around them should make this clear.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:Well, this doesn't constitute a problem, right? If somebody updates them often I guess it's ok, it's not that we can write a rule like "don't update stuff too often" :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::I'm getting too lazy, and lazy people should not infect their surroundings, so I'll just close this... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:04, 16 August 2014 (UTC)<br />
<br />
=== Nice tables ===<br />
<br />
Examples: [https://wiki.archlinux.org/index.php?title=Xorg&diff=327837&oldid=327835], [https://wiki.archlinux.org/index.php?title=Repo-ck&diff=329471&oldid=329461]<br />
<br />
I think that we can afford to have ''nice'', colourful tables. The syntax for wikitables is not very well readable anyway, so a little of HTML will not hurt.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:Still, the HTML syntax is more complex than wiki-tables (and currently discouraged). You'd have to consider where "nice" fits in, compared to simplify editing content, where possible.<br />
:On the topic of HTML, I'd like to bring up a far more extreme example, [[Color_Bash_Prompt]], which seems nigh impossible to change in the standard editor ... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:34, 9 August 2014 (UTC)<br />
<br />
::The readability of wiki tables, both from wiki-text and rendered HTML, depends more on the amount of text inside the table, number of columns, (lack of) additional wiki formatting etc. Of course I agree that generally tables should be kept as simple as possible, but colours can improve the readability of HTML without substantial worsening of the wiki-text readability, so I'd say it's worth to use them.<br />
::And anyway, there is actually a wiki syntax available for specifying attributes for each cell, row, or table as a whole: [[wikipedia:Help:Table#Color.3B_scope_of_parameters]].<br />
::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:28, 9 August 2014 (UTC)<br />
<br />
:::On this topic, I'm for sticking to the no-HTML rule, but I'm perfectly fine with the native way of using CSS as reminded by Lahwaacz.<br />
:::Then there would be the template way of solving this problem, see [[ArchWiki talk:Reports#New templates]].<br />
:::About [[Color Bash Prompt]], that's an exception because HTML is the only way of presenting examples.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::::[[Wikipedia:Template:Table_cell_templates]] would do the trick. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:35, 19 August 2014 (UTC)<br />
<br />
=== Alphabetical order ===<br />
<br />
Example: [https://wiki.archlinux.org/index.php?title=Xorg&diff=prev&oldid=327850]<br />
<br />
Unless in lists (such as [[List of applications]]), alphabetical sorting of sections or other items is useless, I'd even say wrong. Alphabetical sorting is good for finding things, but we have full-text searching nowadays. Even ''chronological'' sorting (assuming that new sections are added to the bottom) is more useful for ''Troubleshooting'' sections.<br />
<br />
Also, have you ever read a book with chapters sorted alphabetically?<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:I think as long as the sorted sections are ''equivalent'' (as in, alphabetical order does not break logical order), you could probably make an argument for both. Should a rule for chronological sorting be found useful, however, I wouldn't object to it. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:41, 9 August 2014 (UTC)<br />
<br />
::Yes, I'd expect a section about a ''new'' bug I am looking a solution for to be at the end of the article. [[User:Axper|axper]] ([[User talk:Axper|talk]]) 06:20, 10 August 2014 (UTC)<br />
<br />
:::First, the example edit should have been split (i.e. one section moved at a time).<br />
:::About the issue, I don't think that alphabetical order can make sense in Troubleshooting or Tips and tricks sections, since the first word of the headings is often incomparable (can be an article, a noun, etc.); chronological order would be better, for example a rule could recommend adding sections at the bottom (or top) of such section groups, unless some similar ones already exist, and in that case I guess keeping similar sections next to each other would be preferable.<br />
:::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::::+1, Lahwaacz is right. And one example for keeping similar sections next to each other: [[GNOME#Extensions]] -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 12:21, 20 August 2014 (UTC)<br />
<br />
=== Concision ===<br />
<br />
(without example)<br />
<br />
Several times recently I was ''amazed'' as to how can be a concise article made even more concise. I think that we need more ''precision over concision''. I think that the ''good'' wiki pages are usually verbose, as the topic is usually too complex to be described concisely. As tempting as it may be, having an expert making it more concise is not helpful for the majority of others.<br />
<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:12, 9 August 2014 (UTC)<br />
<br />
:I think there's a difference between concision in ''style'' and concision in ''content''. Former is a matter of correct writing (convey information that helps understanding, not make it difficult); see [https://wiki.archlinux.org/index.php?title=Skype&diff=prev&oldid=328283] for a simple example. Latter should be avoided, and flagged (for example [https://wiki.archlinux.org/index.php?title=PPTP_Server&curid=9499&diff=329500&oldid=329283]) where appropriate. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:24, 9 August 2014 (UTC)<br />
<br />
::We can indeed put some recommendation like that in the guide, but this is something that the wiki staff will always have to keep an eye on, because experience is the only way to judge, case by case, what's too verbose and what's too concise. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:13, 10 August 2014 (UTC)<br />
<br />
::Thanks for this hint. I've never recognized concision as a [[wikipedia:Concision|term]] and always associated it only with removing of content, either large parts or nuances that might have been intended by the previous editor. Although the [[Help:Style#Language register|language]] should be concise, let's not take it too far. And especially watch out for the nuances. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:08, 10 August 2014 (UTC)<br />
<br />
== Hidden text ==<br />
<br />
:''moved from [[Talk:USB Flash Installation Media]] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:20, 15 August 2014 (UTC)<br />
<br />
Edition 330359, Using manual formatting in Windows.<br />
<br />
Regarding the following edition:<br />
https://wiki.archlinux.org/index.php?title=USB_Flash_Installation_Media&diff=330359&oldid=330302<br />
<br />
In the hidden text ("unhidden" by the edition #330359), I am not disputing the accuracy of the section.<br />
I am purposely leaving a hidden note for future editors.<br />
<br />
Someone could think that the referenced Note is not %100 technically accurate, and he would be correct.<br />
But the technical accuracy needs to be balanced with the real purpose of the wiki article: helping users with their task.<br />
<br />
In this particular case, a deeper technical explanation would make the referenced Note more accurate, but it would unnecessarily over-complicate the text for common users.<br />
<br />
In other words, by adding the hidden note I am "hinting" to potential editors to keep the section "as clear as necessary" for common readers/users so they would be able to perform the task, but without adding or correcting technical details that in practice would not further the real goal of typical readers/users. "As detailed as necessary, but not more than that".<br />
<br />
Therefore, I am inclined to undo the edition #330359 made by [[User:Lahwaacz]].<br />
Would you agree? {{Unsigned|18:51, 15 August 2014|Ady}}<br />
<br />
:HTML comments are neither mentioned in [[Help:Style]], [[Help:Editing]], or similar documents, and in general use of HTML is discouraged. See [[Help:Style#HTML_tags]].<br />
:And to be frank, a distinction between "readers" and "editors" is counterproductive. If a note is deemed not accurate, it should be removed, or if there's uncertainty, it should be mentioned on the talk page. Closing, feel free to re-open if there's doubts. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:37, 15 August 2014 (UTC)<br />
<br />
::Re-opening. IMHO, in certain cases there are differences between "readers" and "editors". The (previously hidden) text is useful for potential editors (those who (should) know enough about the subject), but it would be counterproductive for common users, who are just trying to follow practical steps.<br />
<br />
::I didn't use the hidden text formatting because of style, but because this is precisely the way to help editors without interfering with the normal flow of the text for readers.<br />
<br />
::The usage of <nowiki><!--Comment--></nowiki> for MediaWiki is explained, among other help pages, in http://en.wikipedia.org/wiki/Help:Hidden_text .<br />
::In the same page, http://en.wikipedia.org/wiki/Help:Hidden_text#Appropriate_uses_for_hidden_text :<br />
<br />
:::''Providing information to assist other editors...''<br />
<br />
::since the text would be counterproductive for readers, but useful for editors, I used the standard formatting for any MediaWiki.<br />
<br />
::Certainly the "accuracy" notice being displayed for common readers is counterproductive.<br />
<br />
::If I had to chose between:<br />
::* showing the "accuracy" notice to all readers; or<br />
::* not having the text at all;<br />
::and without the possibility to have the text as "hidden" to help editors, I would choose for not having the text at all, leaving the referenced Note alone.<br />
<br />
::Evidently I am of the opinion that the hidden text is the adequate method for its purpose.<br />
<br />
::Do you still disagree with leaving the text with MediaWiki's hidden formatting? [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 19:08, 15 August 2014 (UTC)<br />
<br />
:::Yes. ArchWiki "readers" are "editors" by definition. From [[The_Arch_Way]]:<br />
<br />
::::Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system. (...)<br />
<br />
::::This user-centric design necessarily implies a certain "do-it-yourself" approach to using the Arch distribution. Rather than pursuing assistance or requesting a new feature to be implemented by developers, Arch Linux users '''have a tendency to solve problems themselves and generously share the results with the community and development team – a "do first, then ask" philosophy.'''<br />
<br />
:::Either way, I see no argument to ''not'' use Talk pages for these purposes. A talk page doesn't interrupt the "normal flow" of reading, yet remains fully transparent. (PS: moving this discussion to [[Help talk:Style]]) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:19, 15 August 2014 (UTC)<br />
<br />
:::: IMHO the Talk pages are for discussions. The hidden formatting is for direct immediate help for a potential future relevant editor (who can clearly and immediately read the hidden text before saving his next related edition). Both methods are valid, because their respective goals and uses are different.<br />
<br />
:::: Even in The Arch Way, no one can know every single technical detail behind every single step. A reader follows the practical steps provided in an article. While the practical steps could be generally understood and successfully followed, there might be deeper technical reasons that are not necessarily understood or known by every reader/user. This is such a case.<br />
<br />
:::: In the particular section of the particular article we are discussing, I happen to know why there is a need for the referenced Note (as opposed to just skip it entirely). The referenced Note is adequate for users following the practical steps, but from a deeper technical level this referenced Note is only "%95" accurate.<br />
<br />
:::: For such "%5 inaccuracy" (which would require a lot of explanations in the wiki article), I'm not going to get into more discussions, specially considering that the practical steps for any user following the article are correct and adequate anyway.<br />
<br />
:::: As I mentioned before, if I had to choose between only two alternatives: either showing the "Accuracy" notice for everyone, or not showing the (previously hidden) text at all (not even for editors), I would choose the latter in this particular case. The reason is clear: the practical steps to be followed by users _are_ accurate.<br />
<br />
:::: The potential discussion about the usefulness of hidden text (aka comments) for editors in very specific cases is for mods, admins and alike. Regarding the particular edition that triggered this discussion about hidden text, I'll edit the wiki article so to delete the text; it will not be hidden, nor shown as "accuracy" notice. Thank you. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 21:27, 15 August 2014 (UTC)<br />
<br />
:::::The problem here is that you don't ''own'' that note, i.e. you have no special rights to indicate whether and how to modify it to other users. The same goes for everybody with every bit of content in every article. We could let users fill the pages with notes telling others how they'd like them to edit their original work, but the result would end up being a total mess, as can be imagined. IMO the only right you have is to discuss future edits (or intentions to edit) with the users who will show interest, and the only wiki way to do it is to add this article in your ''watchlist'' and watch it against counterproductive edits for as long as you are interested.<br />
:::::But where exactly is that note inaccurate? Because usually when you feel some deeper explanations are out of place in some article it's because that article's topic is quite different, so the details should belong somewhere else: is it something regarding [[syslinux]]? Because we have an entire article for it, maybe you could add what's needed there and simply link there from the note?<br />
:::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:59, 16 August 2014 (UTC)<br />
<br />
::::::We keep derailing further from the initial goal. No one claimed, suggested nor thought about owning anything. The purpose of leaving a comment for editors is to help them (editors) without "hurting" the normal flow for readers. MediaWiki uses this formatting as standard, precisely for the purpose I used it for (and I used it for what MediaWiki already considers as a valid, acceptable purpose for leaving hidden text).<br />
<br />
::::::Most frequently an editor won't read a Talk page for an edition where there is no "discussion" needed, specially in long pages with several sections (like it was in this case). The purpose of the "hidden" comment was to effectively "hint and help", not to impose or own anything.<br />
<br />
::::::In this particular case, some potential future editor might think "hmm, the technical background mentioned here is not %100 accurate, let's add several paragraphs of explanations". My "hint" attempted to say "please consider that, although the technical background is not %100 accurate here, the practical steps are clear and effective, there is no real need for additional background in this particular article, and the information already displayed is really needed". In other words, ''balance'' accuracy with clarity and effectiveness.<br />
<br />
::::::If a potential editor would want to ignore (and/or delete) the hint and add more information that is really not needed by the users to be able to follow the steps, then no one can stop him.<br />
<br />
::::::The edition from [[User:Lahwaacz]] said "''don't use HTML comments, they are not rendered''", and he added an "Accuracy" notice instead of the hidden text. Well, I purposely wanted the information to be not rendered for common readers, and my (previously) hidden text read "...it is accurate-enough so to be able to perform the task", which means the _opposite_ of showing the "Accuracy" notice. BTW, please note that [[Help:Style]] was not even mentioned in the reason for his edition.<br />
<br />
::::::As mentioned in http://en.wikipedia.org/wiki/Help:Hidden_text#Appropriate_uses_for_hidden_text , there are _appropriate_ uses for hidden text, and this was one of them.<br />
<br />
::::::Since the discussion has been moved from its original article, the focus has changed, from the technical details regarding "USB Flash Installation Media" and "Syslinux" steps, to "whether in this particular case the usage of 'comments' (aka hidden text) is adequate". In this particular case, I still consider that adding hidden text was appropriate, so to benefit both, readers and editors.<br />
<br />
::::::I have already eliminated the original source that triggered this discussion. I still think that there are valid reasons to use 'comments' in certain cases. Thank you. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 12:47, 16 August 2014 (UTC)<br />
<br />
:::::::There are several assumptions here:<br />
<br />
:::::::1. Editors tend to not read talk pages "where there is no discussion needed" (?)<br />
:::::::2. They particularly don't for "long pages"<br />
:::::::3. Editors always read pages in "Edit" mode<br />
<br />
:::::::I can't speak for others, but personally I have a "reactionary" editing style - I'm a "reader" (regular mode), and when I see something off or want to add something, I enter "Edit" mode. If I'm unsure, I '''collaborate''' edits by mentioning it in the article's talk page, or possibly an editor's talk page (including watchlist, as Kynikos mentioned). I also don't believe point 2 is fair; due to the close/delete policy of ArchWiki, talk pages are most often relevant to the current article and have a good overview. (Admittedly [[Help talk: Style]] is an exception, but that's expected)<br />
<br />
:::::::If you're sure something is ''glaringly'' inaccurate you use [[Template:Accuracy]], or simply fix the article directly (with the time spent to this discussion, it may have been done already...); as Kynikos said, this may include (links to) "outside" content. Otherwise, see the previous paragraph.<br />
<br />
:::::::Personally I'm still unconvinced of adding another method or rule. Re your BTW, not mentioning [[Help:Style]] was most likely an oversight (this is usually mentioned in edit summaries). Anyway, I'm bailing out... I'll see what comments others make. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:28, 16 August 2014 (UTC)<br />
<br />
::::::::@Ady (reopening): first of all I want to make clear that I didn't write the "own[ing]" argument in an accusing way, it was only meant to explain my point of view, I should have added a smiley at the end, I'll do it now :)<br />
::::::::More important, you said we "derail[ed] from the initial goal", but actually I asked you some questions that were very relevant and specific to your edit, and you haven't answered, so I'll paste them here again:<br />
::::::::Where exactly is that note inaccurate? Because usually when you feel some deeper explanations are out of place in some article it's because that article's topic is quite different, so the details should belong somewhere else: is it something regarding [[syslinux]]? Because we have an entire article for it, maybe you could add what's needed there and simply link there from the note?<br />
::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:49, 17 August 2014 (UTC)<br />
<br />
:::::::::@Kynikos, Since the discussion was moved, the focus changed from the more-technical matter to whether using hidden text was/is appropriate (in this particular case). Thus, I thought that perhaps answering those questions here would have been considered off-topic.<br />
<br />
:::::::::The referenced Note says "''The above step installs Syslinux's ldlinux.sys to the VBR of the USB partition, sets the partition as "active/boot" in the MBR partition table and writes the MBR boot code to the 1st 440-byte boot code region of the USB.''". As you can see, this Note is not part of a practical step (and therefore, a slight inaccuracy is likely not going to affect a typical reader following the instructions). Yet, there is a purpose for this Note.<br />
<br />
:::::::::Users kept asking (including to upstream Syslinux) whether they can skip part of the steps, and just copy over ldlinux.sys (for example, to either install or update SYSLINUX in their USB drives). Moreover, some users didn't even ask; they simply (over)wrote this file and they complained that SYSLINUX (and/or Arch) fails to boot. So the Note is there to prevent this type of behavior / confusion / repeated waste of time. This explains why deleting the referenced Note would not be wise.<br />
<br />
:::::::::About the minor inaccuracy... What the SYSLINUX installer does (when performing the specific steps exactly as described in the relevant section of the article) is to:<br />
:::::::::* copy ldlinux.{sys,c32};<br />
:::::::::* patch the VBR so it can point to the correct block in the device (so ldlinux.sys can be found);<br />
:::::::::* set the partition as "active/boot" in the partition table;<br />
:::::::::* write the MBR boot code to the 1st 440-byte boot code region of the USB.<br />
<br />
:::::::::I want to clarify that the above description is only relevant for the specific section we are referring to. The SYSLINUX/EXTLINUX installers perform different tasks according to different cases.<br />
<br />
:::::::::So, there is a minor (technical) background inaccuracy in the Note.<br />
<br />
:::::::::Considering the goal of this Note (as I already described it above) in the context of this particular section of this particular article, and considering that the practical steps provided in the article are not affected by this minor inaccuracy, I asked my self (at the time I performed other editions on the article) whether I should also edit the Note. Would I be actually helping a typical reader that is interested in following the steps? With the objective to balance between accuracy and clarity for the typical reader, I decided not to over-complicate the Note with excessive details that in practical terms only would make the section longer without improving the outcome.<br />
<br />
:::::::::Adding a link to the [[Syslinux]] article would not improve the practical experience / steps for the user in this case. If anyone wants to find more technical information, they don't need yet another link from that same article to the same Syslinux page. In this article, the typical reader is (and/or should better be) likely focused on the practical steps.<br />
<br />
:::::::::Thus, my "hint" was "''This note is not %100 technically accurate, but it is "accurate-enough" so to be able to perform the task.''". For the typical reader trying to follow the practical steps, the procedure is accurate and he will complete the task successfully, so adding an "Accuracy" box would be counterproductive.<br />
<br />
:::::::::Generally speaking, I think there are cases where adding 'comments' (aka hidden text) is adequate, but I am perfectly fine following the guidelines in [[Help:Style]]. Lahwaacz's edition formatted the "hint" as "Accuracy" box, going exactly in the opposite direction of what the hint itself was saying (or at least, against the original intention of the comment). This was not beneficial for users, so I deleted the box.<br />
<br />
:::::::::Slightly long to read (apologies), but I hope this clarifies the matter. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 10:45, 17 August 2014 (UTC)<br />
<br />
::::::::::I see, thanks for explaining, then why not make explicit the reason why the note is there (KISS), like:<br />
::::::::::{{Note|<br />
::::::::::* Make sure to run the above command in full, which installs Syslinux's {{ic|ldlinux.sys}} to the VBR of the USB partition, sets the partition as "active/boot" in the MBR partition table and writes the MBR boot code to the 1st 440-byte boot code region of the USB. Only copying the file, for example in an attempt to update an existing Syslinux installation, will result in an unbootable device.<br />
::::::::::* ...}}<br />
::::::::::This way nobody will see the note as useless and delete it.<br />
::::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:50, 19 August 2014 (UTC)<br />
<br />
:First, sorry for not including the link to [[Help:Style#HTML_tags]] in the edit summary, that was indeed my mistake.<br />
:In addition to the Alad's and Kynikos' replies above, I'd like to remind that ArchWiki is completely different project from Wikipedia and her sister projects, operated by [[wikipedia:Wikimedia Foundation|Wikimedia Foundation]]. ArchWiki has its own sets of rules, that are surely different from the WMF ones. The rule from [[Help:Style#HTML_tags]] regarding HTML comments stands, Alad and Kynikos provided the rationalization. Please respect this rule on ArchWiki.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:34, 16 August 2014 (UTC)<br />
<br />
== Hypertext metaphor interpretation ==<br />
<br />
Regarding [https://wiki.archlinux.org/index.php?title=Talk:VDR&diff=331548&oldid=331546], what is ok to duplicate and what not?<br />
<br />
The relevant rules in [[Help:Style#Hypertext metaphor]] are:<br />
<br />
:* Before writing a specific procedure in an article or describing something in particular, always check if there is already an article that treats that part in detail: in that case, link that article instead of duplicating its content.<br />
:* If the upstream documentation for the subject of your article is well-written and maintained, prefer just writing Arch-specific adaptations and linking to the official documentation for general information.<br />
<br />
''In my view'', the first one refers to internal articles only, so it doesn't apply here. The second should be regulating duplication of external sources. Now, I don't think we can consider https://wiki.debian.org/VDR as the "upstream documentation" for VDR, so I think duplicating the article here could be allowed, as Debian's wiki article (even if written by the same author) can't be considered a more reliable — or better maintained — source than this one. <br />
<br />
I've posted here because I want to discuss the interpretation of those rules in general, and possibly end up improving them to make their meaning clearer.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:57, 21 August 2014 (UTC)<br />
<br />
:You are right that there is no rule to address the issue ''directly'', hence my reply in [[Talk:VDR]] is probably an overstatement. Sometimes I link to [[Help:Style#Hypertext metaphor]] just so that the user gets the general idea.<br />
:To the interpretation of "Hypertext metaphor": IMV, "upstream/official documentation" in the second aforementioned rule ''can be'' "any external resource the editor is currently working with". For some projects, the notion of upstream/official documentation is pretty clear (e.g. [[i3]] with their [http://i3wm.org/docs/userguide.html userguide]), some projects have multiple high-quality "official documentations" (developers' blog posts, manpages, READMEs...), and some projects have none. In the last case it shouldn't matter if the source is hosted on some other distro's wiki or not, they should all have the same priority.<br />
:Regarding maintenance, [[VDR]] is not maintained [https://wiki.archlinux.org/index.php?title=VDR&diff=312049&oldid=239286 since 2012], while [https://wiki.debian.org/VDR Debian's] article has a [https://wiki.debian.org/VDR?action=info stable maintainer] (probably the same person as [[User:Cdwijs]]). This could be a reason both for and against porting the Debian's article here, but maintaining a single article is surely easier than maintaining two.<br />
:It is also questionable if porting an article from MoinMoin (used by Debian's wiki) to MediaWiki syntax can be called a duplication, but I still think it is useless from the reader's point of view.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:07, 21 August 2014 (UTC)<br />
<br />
==<s> Command line text </s>==<br />
<br />
I propose to dis-entangle the templates referenced in first two bullet points of [[Help:Style#Command line text]] as follows: <br />
* When using inline code ([[Template:ic]]), no prompt symbol is to be represented, but any notes about permissions must be added explicitly to the surrounding text.<br />
* When using block code (with [[Template:bc]] or a simple space character in front of each new command line), use {{Ic|$}} as a prompt for regular user commands; use {{Ic|#}} as a prompt for root commands. <br />
<br />
Further to that the bullet points following the note ''could'' be indented one more level to clarify they refer to block code. Having them on the same level as the first two makes it look like they are examples of inline code as well. <br />
<br />
Then there is [[#Ellipses_in_code_examples]] which could be added as a new bullet: <br />
* For code blocks based on a template, e.g. a configuration file, consider focussing the reader to relevant lines and ellipsing ({{ic|...}}) surrounding, non-relevant, code lines. <br />
<br />
in either [[Help:Style#Command line text]] or (better imo) [[Help:Style#Code formatting]]. <br />
--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 08:55, 24 August 2014 (UTC)<br />
<br />
: +1 for all of that -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 10:43, 26 August 2014 (UTC)<br />
<br />
::It's all implemented, thank you Indigo for preparing the text so I could practically just copy and paste it :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:02, 27 August 2014 (UTC)<br />
<br />
==Programming Languages - Introductory Paragraph==<br />
I was looking at the [[Python]] article, and noticed it has a quite verbose description of what Python is, copied from Wikipedia. I would prefer shorter description, which still captures the essentials. In the concrete example, i would pick the first paragraph from [https://docs.python.org/3/tutorial/ python tutorial].<br />
Looking at other articles for Programming Languages, i have noticed an inconsistency. [[D_(programming_language)]] uses the same style (quoting Wikipedia) and [[Java]] also quotes Wikipedia but using a different format. [[Go]], [[Haskell]], [[PHP]] just have a short intro which links to the Language Homepage.This was also the case on the Python article, it was changed there on 2014-07-23.<br />
Would it be a good idea to agree on a common style? Or am i just making a fuss about an unimportant issue?</div>Bwidhttps://wiki.archlinux.org/index.php?title=Talk:Core_utilities&diff=332840Talk:Core utilities2014-08-28T08:26:30Z<p>Bwid: sign</p>
<hr />
<div>== <s>Too many italic word</s> ==<br />
<br />
Too many italic word! Is it legal ? I do not find any text supports it in [[Help: Editing]]. -- [[User:Acgtyrant|Acgtyrant]] ([[User talk:Acgtyrant|talk]]) 15:50, 16 September 2013 (UTC)<br />
:Hi, text formatting on this wiki is regulated by [[Help:Style/Formatting and Punctuation]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:17, 17 September 2013 (UTC)<br />
::So it is, I have never noticed this wiki. Thank your feedback! -- [[User:Acgtyrant|Acgtyrant]] ([[User talk:Acgtyrant|talk]]) 11:05, 18 September 2013 (UTC)<br />
<br />
== Section Reorganization ==<br />
I was thinking of adding descriptions of a few more commands here. Before doing that, i would like to group similar commands together into broad topics. While the current alphabetic ordering is fine if you want to quickly look up a command, i think helpful for beginners if the information is presented in a more structured manner. <br />
<br />
I was thinking of using the following structure:<br />
{{bc|<nowiki><br />
1 directory navigation<br />
ls<br />
mkdir<br />
<br />
2 file manipulation<br />
dd<br />
mv<br />
rm<br />
shred<br />
<br />
3 text processing<br />
cat<br />
grep<br />
iconv<br />
sed<br />
seq<br />
<br />
4 pagers<br />
less<br />
vim as alternative pager<br />
<br />
5 help & search<br />
locate<br />
man<br />
<br />
6 jobs<br />
cron<br />
<br />
7 networking<br />
ip<br />
<br />
8 security<br />
sudo<br />
permissions related utilities<br />
</nowiki>}}<br />
[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 11:35, 27 August 2014 (UTC)<br />
<br />
:I don't know which and how many commands you'd like to add, but the structure devised like that seems to only overcomplicate the page: groups of 1 or 2 commands don't look very useful (pagers, jobs...), and then some choices seem a bit forced, e.g. I wouldn't put mkdir under directory ''navigation'', or grep under text ''processing''; also the coupling of help & search appears a bit arbitrary, why not have a "help & pagers" group instead (just an example to show the arbitrariness).<br />
:Maybe you can expand on the commands you'd like to add, or wait to have some feedback from other users.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:57, 28 August 2014 (UTC)<br />
<br />
::Thanks, you make some very good points. I admit my grouping was quickly thrown together, will be thinking about it some more.<br />
<br />
::About the Commands i was considering, there are 2 Groups. The first is the stuff which could (or should?) be merged from [[Arch Handbook]].<br />
::These are: {cd, find, mount, ps, df, kill}. Now, ''cd'' is so basic that i'm doubting it even belongs here. It would fit more in an "Introduction to the Shell" type of article, aimed at Beginners. I even not sure if this wiki should present such basic information at all. ''find'' is a very powerful command, so a short blurb here can't possible do it justice. But i think it shoud be mentioned, since ''locate'' is. For ''mount'', i was thinking of just linking to the [[Mount]] article.<br />
<br />
::The second group is all the other tools which are in GNU coreutils package. There is a lot of stuff in there, some of it pretty obscure, but some of it is quite useful. I linked a reddit post "a sampling of coreutils" at the bottom of the page a while ago. Here is a list of commands which are currently missing: date echo false ln mknod readlink sleep stty sync touch true uname base64 basename chcon cksum comm csplit cut dircolors dirname du env expand expr fmt fold head id install join md5sum mkfifo nice<br />
::[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 08:26, 28 August 2014 (UTC)</div>Bwidhttps://wiki.archlinux.org/index.php?title=Talk:Core_utilities&diff=332839Talk:Core utilities2014-08-28T08:25:52Z<p>Bwid: Section Reorganization - comment</p>
<hr />
<div>== <s>Too many italic word</s> ==<br />
<br />
Too many italic word! Is it legal ? I do not find any text supports it in [[Help: Editing]]. -- [[User:Acgtyrant|Acgtyrant]] ([[User talk:Acgtyrant|talk]]) 15:50, 16 September 2013 (UTC)<br />
:Hi, text formatting on this wiki is regulated by [[Help:Style/Formatting and Punctuation]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:17, 17 September 2013 (UTC)<br />
::So it is, I have never noticed this wiki. Thank your feedback! -- [[User:Acgtyrant|Acgtyrant]] ([[User talk:Acgtyrant|talk]]) 11:05, 18 September 2013 (UTC)<br />
<br />
== Section Reorganization ==<br />
I was thinking of adding descriptions of a few more commands here. Before doing that, i would like to group similar commands together into broad topics. While the current alphabetic ordering is fine if you want to quickly look up a command, i think helpful for beginners if the information is presented in a more structured manner. <br />
<br />
I was thinking of using the following structure:<br />
{{bc|<nowiki><br />
1 directory navigation<br />
ls<br />
mkdir<br />
<br />
2 file manipulation<br />
dd<br />
mv<br />
rm<br />
shred<br />
<br />
3 text processing<br />
cat<br />
grep<br />
iconv<br />
sed<br />
seq<br />
<br />
4 pagers<br />
less<br />
vim as alternative pager<br />
<br />
5 help & search<br />
locate<br />
man<br />
<br />
6 jobs<br />
cron<br />
<br />
7 networking<br />
ip<br />
<br />
8 security<br />
sudo<br />
permissions related utilities<br />
</nowiki>}}<br />
[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 11:35, 27 August 2014 (UTC)<br />
<br />
:I don't know which and how many commands you'd like to add, but the structure devised like that seems to only overcomplicate the page: groups of 1 or 2 commands don't look very useful (pagers, jobs...), and then some choices seem a bit forced, e.g. I wouldn't put mkdir under directory ''navigation'', or grep under text ''processing''; also the coupling of help & search appears a bit arbitrary, why not have a "help & pagers" group instead (just an example to show the arbitrariness).<br />
:Maybe you can expand on the commands you'd like to add, or wait to have some feedback from other users.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:57, 28 August 2014 (UTC)<br />
<br />
::Thanks, you make some very good points. I admit my grouping was quickly thrown together, will be thinking about it some more.<br />
<br />
::About the Commands i was considering, there are 2 Groups. The first is the stuff which could (or should?) be merged from [[Arch Handbook]].<br />
::These are: {cd, find, mount, ps, df, kill}. Now, ''cd'' is so basic that i'm doubting it even belongs here. It would fit more in an "Introduction to the Shell" type of article, aimed at Beginners. I even not sure if this wiki should present such basic information at all. ''find'' is a very powerful command, so a short blurb here can't possible do it justice. But i think it shoud be mentioned, since ''locate'' is. For ''mount'', i was thinking of just linking to the [[Mount]] article.<br />
<br />
::The second group is all the other tools which are in GNU coreutils package. There is a lot of stuff in there, some of it pretty obscure, but some of it is quite useful. I linked a reddit post "a sampling of coreutils" at the bottom of the page a while ago. Here is a list of commands which are currently missing: date echo false ln mknod readlink sleep stty sync touch true uname base64 basename chcon cksum comm csplit cut dircolors dirname du env expand expr fmt fold head id install join md5sum mkfifo nice</div>Bwidhttps://wiki.archlinux.org/index.php?title=Talk:Core_utilities&diff=332674Talk:Core utilities2014-08-27T11:35:50Z<p>Bwid: Section Reorganization - Proposal to group the commands together into broad topics</p>
<hr />
<div>== <s>Too many italic word</s> ==<br />
<br />
Too many italic word! Is it legal ? I do not find any text supports it in [[Help: Editing]]. -- [[User:Acgtyrant|Acgtyrant]] ([[User talk:Acgtyrant|talk]]) 15:50, 16 September 2013 (UTC)<br />
:Hi, text formatting on this wiki is regulated by [[Help:Style/Formatting and Punctuation]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:17, 17 September 2013 (UTC)<br />
::So it is, I have never noticed this wiki. Thank your feedback! -- [[User:Acgtyrant|Acgtyrant]] ([[User talk:Acgtyrant|talk]]) 11:05, 18 September 2013 (UTC)<br />
<br />
== Section Reorganization ==<br />
I was thinking of adding descriptions of a few more commands here. Before doing that, i would like to group similar commands together into broad topics. While the current alphabetic ordering is fine if you want to quickly look up a command, i think helpful for beginners if the information is presented in a more structured manner. <br />
<br />
I was thinking of using the following structure:<br />
{{bc|<nowiki><br />
1 directory navigation<br />
ls<br />
mkdir<br />
<br />
2 file manipulation<br />
dd<br />
mv<br />
rm<br />
shred<br />
<br />
3 text processing<br />
cat<br />
grep<br />
iconv<br />
sed<br />
seq<br />
<br />
4 pagers<br />
less<br />
vim as alternative pager<br />
<br />
5 help & search<br />
locate<br />
man<br />
<br />
6 jobs<br />
cron<br />
<br />
7 networking<br />
ip<br />
<br />
8 security<br />
sudo<br />
permissions related utilities<br />
</nowiki>}}<br />
[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 11:35, 27 August 2014 (UTC)</div>Bwidhttps://wiki.archlinux.org/index.php?title=User:Bwid&diff=332669User:Bwid2014-08-27T11:14:24Z<p>Bwid: test</p>
<hr />
<div>== todo ==<br />
* Look at how / where in the wiki is the explanation to write X modelines. Maybe improve it. If the method is different from the one i used in bumblebee article, look at resulting modeline and if its different from the one generated by amlc test if still works. Change bumblebee article to just reference the "generate modeline" section elsewhere in the wiki. Look into the xorg-conf snipets that are in the 3-head section of bumblebee article, maybe one of them can be done away with without reducing information content<br />
* "MBR partition table" is likely not really correct terminology. Its basically the boot sector . And the first version of old msdos partition table where contained completely in it? Think about using "msdos partition table" or "classic partition table".<br />
<br />
== somethingelse ==<br />
foo<br />
=== test1 ===<br />
bar</div>Bwidhttps://wiki.archlinux.org/index.php?title=User:Bwid&diff=332668User:Bwid2014-08-27T11:13:33Z<p>Bwid: test</p>
<hr />
<div>== todo ==<br />
* Look at how / where in the wiki is the explanation to write X modelines. Maybe improve it. If the method is different from the one i used in bumblebee article, look at resulting modeline and if its different from the one generated by amlc test if still works. Change bumblebee article to just reference the "generate modeline" section elsewhere in the wiki. Look into the xorg-conf snipets that are in the 3-head section of bumblebee article, maybe one of them can be done away with without reducing information content<br />
* "MBR partition table" is likely not really correct terminology. Its basically the boot sector . And the first version of old msdos partition table where contained completely in it? Think about using "msdos partition table" or "classic partition table".<br />
<br />
== test1 ==<br />
foo<br />
=== test2 ===<br />
bar</div>Bwidhttps://wiki.archlinux.org/index.php?title=User:Bwid&diff=332667User:Bwid2014-08-27T11:13:03Z<p>Bwid: test</p>
<hr />
<div>== todo ==<br />
* Look at how / where in the wiki is the explanation to write X modelines. Maybe improve it. If the method is different from the one i used in bumblebee article, look at resulting modeline and if its different from the one generated by amlc test if still works. Change bumblebee article to just reference the "generate modeline" section elsewhere in the wiki. Look into the xorg-conf snipets that are in the 3-head section of bumblebee article, maybe one of them can be done away with without reducing information content<br />
* "MBR partition table" is likely not really correct terminology. Its basically the boot sector . And the first version of old msdos partition table where contained completely in it? Think about using "msdos partition table" or "classic partition table".<br />
<br />
== test1 ==<br />
foo</div>Bwidhttps://wiki.archlinux.org/index.php?title=User:Bwid&diff=332666User:Bwid2014-08-27T11:12:14Z<p>Bwid: test</p>
<hr />
<div>== todo ==<br />
* Look at how / where in the wiki is the explanation to write X modelines. Maybe improve it. If the method is different from the one i used in bumblebee article, look at resulting modeline and if its different from the one generated by amlc test if still works. Change bumblebee article to just reference the "generate modeline" section elsewhere in the wiki. Look into the xorg-conf snipets that are in the 3-head section of bumblebee article, maybe one of them can be done away with without reducing information content<br />
* "MBR partition table" is likely not really correct terminology. Its basically the boot sector . And the first version of old msdos partition table where contained completely in it? Think about using "msdos partition table" or "classic partition table".<br />
<br />
== test 1 ==<br />
foo</div>Bwidhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=332214Open-iSCSI2014-08-24T12:30:35Z<p>Bwid: "Configuration" Section, to be more consistent with other articles</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
This article describes how to access an iSCSI target with the [http://open-iscsi.org/ Open-iSCSI] initiator.<br />
<br />
== Installation ==<br />
[[pacman|Install]] the {{Pkg|open-iscsi}} package from the [[official repositories]].<br />
<br />
{{Note|An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI in April 2005.<br />
This should not be confused with [http://linux-iscsi.org/ linux-iscsi.org], the website for the LIO [[iSCSI Target|target]].}}<br />
<br />
== Overview ==<br />
The following diagram shows how the Components work together. A more detailed version can be found here: [http://www.open-iscsi.org/docs/open-iscsi-0.jpg Open-iSCSI modules]<br />
{{bc|<nowiki><br />
+-------------------------------------------------------+ <br />
| Targets & Sessions configuration Database (DBM based) | <br />
+-------------------------------------------------------+ <br />
<br />
+--------------------------+ +----------------------------------+ <br />
| iscsiadm | | iscsid: iSCSI daemon | <br />
| | | | <br />
| * Command line tool |<--->| * Implements Session management | <br />
| * Manages database of | | * Communicates with iscsiadm | <br />
| sessions and targets | | and iscsi kernel modules | <br />
+--------------------------+ +---------------+------------------+ <br />
| <br />
User space | <br />
- - - - - - - - - - - - - - - - - - - - - - - - - | - - - - - - - - - -<br />
Kernel v <br />
+-----------------------------------------------------------+ <br />
| kernel modules: scsi_transport_iscsi, iscsi_tcp, libiscsi | <br />
+-----------------------------------------------------------+ <br />
</nowiki>}}<br />
<br />
From the Open-iSCSI [http://www.open-iscsi.org/docs/README README]:<br />
<br />
Persistent configuration is implemented as a DBM database, which contains two tables:<br />
* Discovery table (/etc/iscsi/send_targets)<br />
* Node table (/etc/iscsi/nodes)<br />
<br />
== Configuration ==<br />
=== Start the Service ===<br />
{{ic|iscsid}} is managed by a systemd Unit.<br />
<br />
Start {{ic|open-iscsi.service}} [[systemd#Using units|using systemd]]. <br />
<br />
{{Out of date|The following advice about /etc/conf.d/open-iscsi might be out of date, see discussion page}} <br />
You only have to include the IP of the [[iSCSI Target|target]] as {{ic|SERVER}} in {{ic|/etc/conf.d/open-iscsi}} at the client.<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips & Troubleshooting ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
Many of the {{ic|iscsiadm}} operations require that the iSCSI daemon {{ic|iscsid}} is running. To verify that this is the case, <br />
[[systemd#Using units|check the status]] of the {{ic|open-iscsi.service}}.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Bwidhttps://wiki.archlinux.org/index.php?title=Xinit&diff=332209Xinit2014-08-24T11:17:34Z<p>Bwid: Related: Xresources</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Desktop environments]]<br />
[[Category:X Server]]<br />
[[de:Xinitrc]]<br />
[[el:Xinitrc]]<br />
[[es:Xinitrc]]<br />
[[fr:Startx]]<br />
[[it:Xinitrc]]<br />
[[ja:Xinitrc]]<br />
[[zh-CN:Xinitrc]]<br />
{{Related articles start}}<br />
{{Related|Display manager}}<br />
{{Related|Start X at Login}}<br />
{{Related|Xorg}}<br />
{{Related|xprofile}}<br />
{{Related|Xresources}}<br />
{{Related articles end}}<br />
<br />
The {{ic|~/.xinitrc}} file is a shell script read by {{ic|xinit}} and by its front-end {{ic|startx}}. It is mainly used to execute [[desktop environment]]s, [[window manager]]s and other programs when starting the X server (e.g., starting daemons and setting environment variables). The {{ic|xinit}} program starts the [[Xorg|X Window System]] server and works as first client program on systems that are not using a [[display manager]].<br />
<br />
One of the main functions of {{ic|~/.xinitrc}} is to dictate which client for the X Window System is invoked with {{ic|startx}} or {{ic|xinit}} programs on a per-user basis. There exists numerous additional specifications and commands that may also be added to {{ic|~/.xinitrc}} as you further customize your system.<br />
<br />
Most DMs also source the similar [[xprofile]] before xinit.<br />
<br />
== Getting started ==<br />
<br />
{{ic|/etc/skel/}} contains files and directories to provide sane defaults for newly created user accounts. (The name ''skel'' is derived from the word ''skeleton'', because the files it contains form the basic structure for users' home directories.) The {{Pkg|xorg-xinit}} package will populate {{ic|/etc/skel}} with a framework {{ic|.xinitrc}} file.<br />
<br />
Copy the sample {{ic|/etc/skel/.xinitrc}} file to your home directory:<br />
$ cp /etc/skel/.xinitrc ~<br />
<br />
Now, edit {{ic|~/.xinitrc}} and uncomment the line that corresponds to your DE/WM. For example, if you want to test your basic X configuration (mouse, keyboard, graphics resolution), you can simply use [[xterm]]:<br />
<br />
{{bc|<br />
#!/bin/sh<br />
#<br />
# ~/.xinitrc<br />
#<br />
# Executed by startx (run your window manager from here)<br />
<br />
if [ -d /etc/X11/xinit/xinitrc.d ]; then<br />
for f in /etc/X11/xinit/xinitrc.d/*; do<br />
[ -x "$f" ] && . "$f"<br />
done<br />
unset f<br />
fi<br />
<br />
# exec gnome-session<br />
# exec startkde<br />
# exec startxfce4<br />
# exec wmaker<br />
# exec icewm<br />
# exec blackbox<br />
# exec fluxbox<br />
# exec openbox-session<br />
# exec cinnamon-session<br />
# ...or the Window Manager of your choice<br />
exec xterm<br />
}}<br />
<br />
{{Note|Make sure to uncomment only one {{ic|exec}} line, since that will be the last command run from the script; all the following lines will just be ignored. Do NOT attempt to background your WM by appending a `&` to the line.}}<br />
<br />
After editing {{ic|~/.xinitrc}} properly, it's time to run X. To run X as a non-root user, issue:<br />
$ startx<br />
<br />
or<br />
<br />
$ xinit -- :1 -nolisten tcp vt$XDG_VTNR<br />
<br />
{{Note|<br />
* {{ic|xinit}} doesn't read the system-wide {{ic|/etc/X11/xinit/xserverrc}} file, so you either have to copy it into your home directory as name {{ic|.xserverrc}}, or specify {{ic|vt$XDG_VTNR}} as command line option in order to [[General troubleshooting#Session permissions|preserve session permissions]].<br />
*{{ic|xinit}} doesn't handle multiple sessions if you are already logged-in into some other virtual terminal. For that you have to specify session by appending {{ic|-- :''session_no''}}. If you are already running X then you should start with :1 or more.}}<br />
<br />
Your DE/WM of choice should now start up. You are now free to test your keyboard with its layout, moving your mouse around and of course enjoy the view.<br />
<br />
== Configuration ==<br />
<br />
When a display manager is not used, it is important to keep in mind that the life of the X session starts and ends with {{ic|~/.xinitrc}}. This means that once the script quits, X quits regardless of whether you still have running programs (including your window manager). Therefore it's important that the window manager quitting and X quitting should coincide. This is easily achieved by running the window manager as the last program in the script.<br />
<br />
Following is a simple {{ic|~/.xinitrc}} file example, including some startup programs:<br />
<br />
{{hc|~/.xinitrc|<nowiki><br />
#!/bin/sh<br />
<br />
if [ -d /etc/X11/xinit/xinitrc.d ]; then<br />
for f in /etc/X11/xinit/xinitrc.d/*; do<br />
[ -x "$f" ] && . "$f"<br />
done<br />
unset f<br />
fi<br />
<br />
xrdb -merge ~/.Xresources # update x resources db<br />
<br />
xscreensaver -no-splash & # starts screensaver daemon <br />
xsetroot -cursor_name left_ptr & # sets the cursor icon<br />
sh ~/.fehbg & # sets the background image<br />
<br />
exec openbox-session # starts the window manager<br />
</nowiki>}}<br />
<br />
Note that in the example above, programs such as {{ic|xscreensaver}}, {{ic|xsetroot}} and {{ic|sh}} are run in the background ({{ic|&}} suffix added). Otherwise, the script would halt and wait for each program and daemons to exit before executing {{ic|openbox-session}}. Also note that {{ic|openbox-session}} is not backgrounded. This ensures that the script will not quit until openbox does.<br />
<br />
Prepending the window manager {{ic|openbox-session}} with {{ic|exec}} is recommended as it replaces the current process with that process, so the script will stop running and X won't exit even if the process forks into the background.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Override xinitrc from command line ===<br />
<br />
If you have a working {{ic|~/.xinitrc}}, but just want to try other WM/DE, you can run it by issuing {{ic|startx}} followed by the path to the window manager:<br />
<br />
$ startx /full/path/to/window-manager<br />
<br />
Note that the full path is '''required'''. Optionally, you can also override {{ic|/etc/X11/xinit/xserverrc}} file (which stores the default X server options) with custom options by appending them after {{ic|--}}, e.g.:<br />
<br />
$ startx /usr/bin/enlightenment -- -nolisten tcp -br +bs -dpi 96 vt$XDG_VTNR<br />
<br />
or<br />
<br />
$ xinit /usr/bin/enlightenment -- -nolisten tcp -br +bs -dpi 96 vt$XDG_VTNR<br />
<br />
=== Making a DE/WM choice ===<br />
<br />
If you are frequently switching between different DEs/WMs, it is recommended to either use a [[Display manager]] or add code to {{ic|.xinitrc}}. The code described next consists of a simple few lines, which will take the argument and load the desired desktop environment or window manager.<br />
<br />
The following example {{ic|~/.xinitrc}} shows how to start a particular DE/WM with an argument:<br />
<br />
{{hc|~/.xinitrc|<nowiki><br />
#!/bin/sh<br />
#<br />
# ~/.xinitrc<br />
#<br />
# Executed by startx (run your window manager from here)<br />
<br />
if [ -d /etc/X11/xinit/xinitrc.d ]; then<br />
for f in /etc/X11/xinit/xinitrc.d/*; do<br />
[ -x "$f" ] && . "$f"<br />
done<br />
unset f<br />
fi<br />
<br />
# Here Xfce is kept as default<br />
session=${1:-xfce}<br />
<br />
case $session in<br />
awesome ) exec awesome;;<br />
bspwm ) exec bspwm;;<br />
catwm ) exec catwm;;<br />
cinnamon ) exec cinnamon-session;;<br />
dwm ) exec dwm;;<br />
enlightenment ) exec enlightenment_start;;<br />
ede ) exec startede;;<br />
fluxbox ) exec startfluxbox;;<br />
gnome ) exec gnome-session;;<br />
gnome-classic ) exec gnome-session --session=gnome-classic;;<br />
i3|i3wm ) exec i3;;<br />
icewm ) exec icewm-session;;<br />
jwm ) exec jwm;;<br />
kde ) exec startkde;;<br />
mate ) exec mate-session;;<br />
monster|monsterwm ) exec monsterwm;;<br />
notion ) exec notion;;<br />
openbox ) exec openbox-session;;<br />
unity ) exec unity;;<br />
xfce|xfce4 ) exec startxfce4;;<br />
xmonad ) exec xmonad;;<br />
# No known session, try to run it as command<br />
*) exec $1;;<br />
esac<br />
<br />
</nowiki>}}<br />
<br />
Then copy the {{ic|/etc/X11/xinit/xserverrc}} file into your home directory:<br />
<br />
$ cp /etc/X11/xinit/xserverrc ~/.xserverrc<br />
<br />
After that, you can easily start a particular DE/WM by passing an argument, e.g.:<br />
<br />
$ xinit<br />
$ xinit gnome<br />
$ xinit kde<br />
$ xinit wmaker<br />
<br />
or<br />
<br />
$ startx<br />
$ startx ~/.xinitrc gnome<br />
$ startx ~/.xinitrc kde<br />
$ startx ~/.xinitrc wmaker</div>Bwidhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=332208Open-iSCSI2014-08-24T10:57:47Z<p>Bwid: System Overview</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
This article describes how to access an iSCSI target with the [http://open-iscsi.org/ Open-iSCSI] initiator.<br />
<br />
== Installation ==<br />
[[pacman|Install]] the {{Pkg|open-iscsi}} package from the [[official repositories]].<br />
<br />
{{Note|An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI in April 2005.<br />
This should not be confused with [http://linux-iscsi.org/ linux-iscsi.org], the website for the LIO [[iSCSI Target|target]].}}<br />
<br />
== Overview ==<br />
The following diagram shows how the Components work together. A more detailed version can be found here: [http://www.open-iscsi.org/docs/open-iscsi-0.jpg Open-iSCSI modules]<br />
{{bc|<nowiki><br />
+-------------------------------------------------------+ <br />
| Targets & Sessions configuration Database (DBM based) | <br />
+-------------------------------------------------------+ <br />
<br />
+--------------------------+ +----------------------------------+ <br />
| iscsiadm | | iscsid: iSCSI daemon | <br />
| | | | <br />
| * Command line tool |<--->| * Implements Session management | <br />
| * Manages database of | | * Communicates with iscsiadm | <br />
| sessions and targets | | and iscsi kernel modules | <br />
+--------------------------+ +---------------+------------------+ <br />
| <br />
User space | <br />
- - - - - - - - - - - - - - - - - - - - - - - - - | - - - - - - - - - -<br />
Kernel v <br />
+-----------------------------------------------------------+ <br />
| kernel modules: scsi_transport_iscsi, iscsi_tcp, libiscsi | <br />
+-----------------------------------------------------------+ <br />
</nowiki>}}<br />
<br />
From the Open-iSCSI [http://www.open-iscsi.org/docs/README README]:<br />
<br />
Persistent configuration is implemented as a DBM database, which contains two tables:<br />
* Discovery table (/etc/iscsi/send_targets)<br />
* Node table (/etc/iscsi/nodes)<br />
<br />
== Start the Service ==<br />
Start {{ic|open-iscsi.service}} [[systemd#Using units|using systemd]].<br />
<br />
{{Out of date|The following advice about /etc/conf.d/open-iscsi might be out of date, see discussion page}} <br />
You only have to include the IP of the [[iSCSI Target|target]] as {{ic|SERVER}} in {{ic|/etc/conf.d/open-iscsi}} at the client.<br />
<br />
== Using the Tools ==<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips & Troubleshooting ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
Many of the {{ic|iscsiadm}} operations require that the iSCSI daemon {{ic|iscsid}} is running. To verify that this is the case, <br />
[[systemd#Using units|check the status]] of the {{ic|open-iscsi.service}}.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Bwidhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=332086Open-iSCSI2014-08-24T00:42:09Z<p>Bwid: Move advice "daemon has to be running" down into Troubleshooting section, since this should be the case if the user follows instructions and starts the service.</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
This article describes how to access an iSCSI target with the [http://open-iscsi.org/ Open-iSCSI] initiator.<br />
<br />
== Installation ==<br />
[[pacman|Install]] the {{Pkg|open-iscsi}} package from the [[official repositories]].<br />
<br />
{{Note|An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI in April 2005.<br />
This should not be confused with [http://linux-iscsi.org/ linux-iscsi.org], the website for the LIO [[iSCSI Target|target]].}}<br />
<br />
== Start the Service ==<br />
Start {{ic|open-iscsi.service}} [[systemd#Using units|using systemd]].<br />
<br />
{{Out of date|The following advice about /etc/conf.d/open-iscsi might be out of date, see discussion page}} <br />
You only have to include the IP of the [[iSCSI Target|target]] as {{ic|SERVER}} in {{ic|/etc/conf.d/open-iscsi}} at the client.<br />
<br />
== Using the Tools ==<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips & Troubleshooting ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
Many of the {{ic|iscsiadm}} operations require that the iSCSI daemon {{ic|iscsid}} is running. To verify that this is the case, <br />
[[systemd#Using units|check the status]] of the {{ic|open-iscsi.service}}.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Bwidhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=332085Open-iSCSI2014-08-24T00:27:51Z<p>Bwid: rename section: Tips & Troubleshooting</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
This article describes how to access an iSCSI target with the [http://open-iscsi.org/ Open-iSCSI] initiator.<br />
<br />
== Installation ==<br />
[[pacman|Install]] the {{Pkg|open-iscsi}} package from the [[official repositories]].<br />
<br />
{{Note|An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI in April 2005.<br />
This should not be confused with [http://linux-iscsi.org/ linux-iscsi.org], the website for the LIO [[iSCSI Target|target]].}}<br />
<br />
== Start the Service ==<br />
Start {{ic|open-iscsi.service}} [[systemd#Using units|using systemd]].<br />
<br />
{{Out of date|The following advice about /etc/conf.d/open-iscsi might be out of date, see discussion page}} <br />
You only have to include the IP of the [[iSCSI Target|target]] as {{ic|SERVER}} in {{ic|/etc/conf.d/open-iscsi}} at the client.<br />
<br />
== Using the Tools ==<br />
{{ic|iscsid}} has to be running.<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips & Troubleshooting ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Bwidhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=332084Open-iSCSI2014-08-24T00:24:49Z<p>Bwid: /* Using the Daemon -> Start the Service */ rename section</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
This article describes how to access an iSCSI target with the [http://open-iscsi.org/ Open-iSCSI] initiator.<br />
<br />
== Installation ==<br />
[[pacman|Install]] the {{Pkg|open-iscsi}} package from the [[official repositories]].<br />
<br />
{{Note|An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI in April 2005.<br />
This should not be confused with [http://linux-iscsi.org/ linux-iscsi.org], the website for the LIO [[iSCSI Target|target]].}}<br />
<br />
== Start the Service ==<br />
Start {{ic|open-iscsi.service}} [[systemd#Using units|using systemd]].<br />
<br />
{{Out of date|The following advice about /etc/conf.d/open-iscsi might be out of date, see discussion page}} <br />
You only have to include the IP of the [[iSCSI Target|target]] as {{ic|SERVER}} in {{ic|/etc/conf.d/open-iscsi}} at the client.<br />
<br />
== Using the Tools ==<br />
{{ic|iscsid}} has to be running.<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Bwidhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=332083Open-iSCSI2014-08-24T00:17:13Z<p>Bwid: /* Using the Daemon */ add out of date warning</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
This article describes how to access an iSCSI target with the [http://open-iscsi.org/ Open-iSCSI] initiator.<br />
<br />
== Installation ==<br />
[[pacman|Install]] the {{Pkg|open-iscsi}} package from the [[official repositories]].<br />
<br />
{{Note|An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI in April 2005.<br />
This should not be confused with [http://linux-iscsi.org/ linux-iscsi.org], the website for the LIO [[iSCSI Target|target]].}}<br />
<br />
=== Using the Daemon ===<br />
Start {{ic|open-iscsi.service}} [[systemd#Using units|using systemd]].<br />
<br />
{{Out of date|The following advice about /etc/conf.d/open-iscsi might be out of date, see discussion page}} <br />
You only have to include the IP of the [[iSCSI Target|target]] as {{ic|SERVER}} in {{ic|/etc/conf.d/open-iscsi}} at the client.<br />
<br />
== Using the Tools ==<br />
{{ic|iscsid}} has to be running.<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Bwidhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=332082Open-iSCSI2014-08-24T00:13:05Z<p>Bwid: /* Using the Daemon */ changed acc. to Help:Style#Daemon_operations</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
This article describes how to access an iSCSI target with the [http://open-iscsi.org/ Open-iSCSI] initiator.<br />
<br />
== Installation ==<br />
[[pacman|Install]] the {{Pkg|open-iscsi}} package from the [[official repositories]].<br />
<br />
{{Note|An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI in April 2005.<br />
This should not be confused with [http://linux-iscsi.org/ linux-iscsi.org], the website for the LIO [[iSCSI Target|target]].}}<br />
<br />
=== Using the Daemon ===<br />
You only have to include the IP of the [[iSCSI Target|target]] as {{ic|SERVER}} in {{ic|/etc/conf.d/open-iscsi}} at the client.<br />
<br />
Start {{ic|open-iscsi.service}} [[systemd#Using units|using systemd]].<br />
<br />
== Using the Tools ==<br />
{{ic|iscsid}} has to be running.<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Bwidhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=332081Open-iSCSI2014-08-23T23:58:47Z<p>Bwid: Configuration which might be necessary on the remote is not directly related to daemon config. move to tips section.</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
This article describes how to access an iSCSI target with the [http://open-iscsi.org/ Open-iSCSI] initiator.<br />
<br />
== Installation ==<br />
[[pacman|Install]] the {{Pkg|open-iscsi}} package from the [[official repositories]].<br />
<br />
{{Note|An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI in April 2005.<br />
This should not be confused with [http://linux-iscsi.org/ linux-iscsi.org], the website for the LIO [[iSCSI Target|target]].}}<br />
<br />
=== Using the Daemon ===<br />
You only have to include the IP of the [[iSCSI Target|target]] as {{ic|SERVER}} in {{ic|/etc/conf.d/open-iscsi}} at the client.<br />
<br />
<br />
After both steps are finished you should be able to start the initiator with {{bc|# systemctl enable open-iscsi.service<br />
# systemctl start open-iscsi.service}}<br />
You can see the current sessions with {{bc|# systemctl status open-iscsi.service}}<br />
<br />
== Using the Tools ==<br />
{{ic|iscsid}} has to be running.<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Bwidhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=332080Open-iSCSI2014-08-23T23:53:56Z<p>Bwid: /* Installation */</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
This article describes how to access an iSCSI target with the [http://open-iscsi.org/ Open-iSCSI] initiator.<br />
<br />
== Installation ==<br />
[[pacman|Install]] the {{Pkg|open-iscsi}} package from the [[official repositories]].<br />
<br />
{{Note|An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI in April 2005.<br />
This should not be confused with [http://linux-iscsi.org/ linux-iscsi.org], the website for the LIO [[iSCSI Target|target]].}}<br />
<br />
=== Using the Daemon ===<br />
You only have to include the IP of the [[iSCSI Target|target]] as {{ic|SERVER}} in {{ic|/etc/conf.d/open-iscsi}} at the client.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
After both steps are finished you should be able to start the initiator with {{bc|# systemctl enable open-iscsi.service<br />
# systemctl start open-iscsi.service}}<br />
You can see the current sessions with {{bc|# systemctl status open-iscsi.service}}<br />
<br />
== Using the Tools ==<br />
{{ic|iscsid}} has to be running.<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Bwidhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=332079Open-iSCSI2014-08-23T23:52:55Z<p>Bwid: Rename section to Installation, to make uniform with other articles.</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
This article describes how to access an iSCSI target with the [http://open-iscsi.org/ Open-iSCSI] initiator.<br />
<br />
== Installation ==<br />
[[pacman|Install]] {{Pkg|open-iscsi}} package from the [[official repositories]].<br />
<br />
{{Note|An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI in April 2005.<br />
This should not be confused with [http://linux-iscsi.org/ linux-iscsi.org], the website for the LIO [[iSCSI Target|target]].}}<br />
<br />
=== Using the Daemon ===<br />
You only have to include the IP of the [[iSCSI Target|target]] as {{ic|SERVER}} in {{ic|/etc/conf.d/open-iscsi}} at the client.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
After both steps are finished you should be able to start the initiator with {{bc|# systemctl enable open-iscsi.service<br />
# systemctl start open-iscsi.service}}<br />
You can see the current sessions with {{bc|# systemctl status open-iscsi.service}}<br />
<br />
== Using the Tools ==<br />
{{ic|iscsid}} has to be running.<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Bwidhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=332078Open-iSCSI2014-08-23T23:47:33Z<p>Bwid: move info about old the linux-iscsi project into Note in Install section</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
This article describes how to access an iSCSI target with the [http://open-iscsi.org/ Open-iSCSI] initiator.<br />
<br />
== Setup With Open-iSCSI ==<br />
{{Pkg|open-iscsi}} is available in the official repositories. Install it with {{bc|# pacman -S open-iscsi}}<br />
<br />
{{Note|An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI in April 2005.<br />
This should not be confused with [http://linux-iscsi.org/ linux-iscsi.org], the website for the LIO [[iSCSI Target|target]].}}<br />
<br />
=== Using the Daemon ===<br />
You only have to include the IP of the [[iSCSI Target|target]] as {{ic|SERVER}} in {{ic|/etc/conf.d/open-iscsi}} at the client.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
After both steps are finished you should be able to start the initiator with {{bc|# systemctl enable open-iscsi.service<br />
# systemctl start open-iscsi.service}}<br />
You can see the current sessions with {{bc|# systemctl status open-iscsi.service}}<br />
<br />
== Using the Tools ==<br />
{{ic|iscsid}} has to be running.<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Bwidhttps://wiki.archlinux.org/index.php?title=Open-iSCSI&diff=332077Open-iSCSI2014-08-23T23:39:59Z<p>Bwid: brought short back article summary sentence</p>
<hr />
<div>[[Category:Storage]]<br />
[[Category:Networking]]<br />
{{Related articles start}}<br />
{{Related|iSCSI Target}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
With [[Wikipedia:iSCSI]] you can access storage over an IP-based network.<br />
<br />
The exported storage entity is the '''[[iSCSI Target|target]]''' and the importing entity is the '''initiator'''.<br />
<br />
This article describes how to access an iSCSI target with the [http://open-iscsi.org/ Open-iSCSI] initiator.<br />
<br />
The preferred initiator is [http://open-iscsi.org/ Open-iSCSI] as of 2011. An older initiator, [http://sourceforge.net/projects/linux-iscsi/ Linux-iSCSI], was merged with Open-iSCSI.<br />
Linux-iSCSI should not be confused with linux-iscsi.org, the website for the LIO [[iSCSI Target|target]].<br />
<br />
== Setup With Open-iSCSI ==<br />
{{Pkg|open-iscsi}} is available in the official repositories. Install it with {{bc|# pacman -S open-iscsi}}<br />
<br />
=== Using the Daemon ===<br />
You only have to include the IP of the [[iSCSI Target|target]] as {{ic|SERVER}} in {{ic|/etc/conf.d/open-iscsi}} at the client.<br />
<br />
At the server (target) you might need to include the client iqn from {{ic|/etc/iscsi/initiatorname.iscsi}} in the acl configuration.<br />
<br />
After both steps are finished you should be able to start the initiator with {{bc|# systemctl enable open-iscsi.service<br />
# systemctl start open-iscsi.service}}<br />
You can see the current sessions with {{bc|# systemctl status open-iscsi.service}}<br />
<br />
== Using the Tools ==<br />
{{ic|iscsid}} has to be running.<br />
<br />
=== Target discovery ===<br />
{{bc|# iscsiadm -m discovery -t sendtargets -p <portalip>}}<br />
=== Delete obsolete targets ===<br />
{{bc|# iscsiadm -m discovery -p <portalip> -o delete}}<br />
<br />
=== Login to available targets ===<br />
{{bc|# iscsiadm -m node -L all}}<br />
or login to specific target<br />
{{bc|<nowiki># iscsiadm -m node --targetname=<targetname> --login</nowiki>}}<br />
<br />
logout:<br />
{{bc|# iscsiadm -m node -U all}}<br />
<br />
=== Info ===<br />
For running session<br />
{{bc|# iscsiadm -m session -P 3}}<br />
The last line of the above command will show the name of the attached dev e.g<br />
{{bc|Attached scsi disk '''sdd''' State: running}}<br />
<br />
For the known nodes<br />
{{bc|# iscsiadm -m node}}<br />
<br />
=== Online resize of volumes ===<br />
If the iscsi blockdevice contains a partitiontable, you will not be able to do an online resize. In this case you have to unmount the filesystem and alter the size of the affected partition.<br />
# Rescan active nodes in current session {{bc|# iscsiadm -m node -R}}<br />
# If you use multipath, you also have to rescan multipath volume information. {{bc|# multipathd -k"resize map sdx"}}<br />
# Finally resize the filesystem. {{bc|# resize2fs /dev/sdx}}<br />
<br />
== Tips ==<br />
You can also check where the attached iSCSI devices are located in the /dev tree with {{ic|ls -lh /dev/disk/by-path/* | grep ip}}.<br />
<br />
== See also ==<br />
* [[iSCSI Boot]] Booting Arch Linux with / on an iSCSI target.</div>Bwidhttps://wiki.archlinux.org/index.php?title=Talk:Open-iSCSI&diff=332063Talk:Open-iSCSI2014-08-23T21:36:56Z<p>Bwid: Is the /etc/conf.d/open-iscsi file still used?</p>
<hr />
<div>== Is the /etc/conf.d/open-iscsi file still used? ==<br />
<br />
I am planning to do a small rewrite/reorg, to bring some things in line with style guide, <br />
and also to make the Section headline organization clearer.<br />
<br />
This sentence confuses me: "You only have to include the IP of the target as SERVER in /etc/conf.d/open-iscsi at the client."<br />
<br />
I *think* this is a remnant for the old rc-script Version of the package. The file doesn't exist in the current package. <br />
<br />
However i'm not completely sure. I downloaded the current version of the open-iscsi from ABS, and it still has a "open-iscsi.conf.d" file. It looks to me like this file isn't used by the PKGBUILD at all, and i can just ignore it and thus delete the above sentence.<br />
<br />
I plan to replace it by a short paragraph on how to Automate Target Logins for Future System Statups (as explained in the /usr/share/doc/open-iscsi/README)<br />
<br />
[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 21:36, 23 August 2014 (UTC)</div>Bwidhttps://wiki.archlinux.org/index.php?title=Iptables&diff=330527Iptables2014-08-16T09:20:06Z<p>Bwid: /* Viewing logged packets */ less verbose</p>
<hr />
<div>{{DISPLAYTITLE:iptables}}<br />
[[Category:Firewalls]]<br />
[[es:Iptables]]<br />
[[fr:Iptables]]<br />
[[it:Iptables]]<br />
[[ru:Iptables]]<br />
[[sr:Iptables]]<br />
[[zh-CN:Iptables]]<br />
{{Related articles start}}<br />
{{Related|Firewalls}}<br />
{{Related|Simple stateful firewall}}<br />
{{Related|Sysctl#TCP/IP stack hardening}}<br />
{{Related|Sshguard}}<br />
{{Related|Fail2ban}}<br />
{{Related|Nftables}}<br />
{{Related articles end}}<br />
<br />
Iptables is a powerful [[firewall]] built into the Linux kernel and is part of the [[Wikipedia:Netfilter|netfilter]] project. It can be configured directly, or by using one of the many [[Firewalls#iptables_front-ends|frontends]] and [[Firewall#iptables_GUIs|GUIs]]. iptables is used for [[Wikipedia:IPv4|IPv4]] and ip6tables is used for [[IPv6]].<br />
<br />
[[nftables]] was released in [http://www.phoronix.com/scan.php?page=news_item&px=MTQ5MDU release with Linux kernel 3.13], and will one day replace iptables as the main Linux firewall utility.<br />
<br />
== Installation ==<br />
<br />
The stock Arch Linux kernel is compiled with iptables support. You will only need to [[pacman|install]] the userland utilities, which are provided by the package {{Pkg|iptables}} in the [[official repositories]]. (The {{Pkg|iproute2}} package from the {{Grp|base}} group depends on iptables, so the iptables package should be installed on your system by default.)<br />
<br />
== Basic concepts ==<br />
<br />
iptables is used to inspect, modify, forward, redirect, and/or drop IPv4 packets. The code for filtering IPv4 packets is already built into the kernel and is organized into a collection of ''tables'', each with a specific purpose. The tables are made up of a set of predefined ''chains'', and the chains contain rules which are traversed in order. Each rule consists of a predicate of potential matches and a corresponding action (called a ''target'') which is executed if the predicate is true; i.e. the conditions are matched. iptables is the user utility which allow you to work with these chains/rules. Most new users find the complexities of linux IP routing quite daunting, but, in practice, the most common use cases (NAT and/or basic Internet firewall) are considerably less complex.<br />
<br />
The key to understanding how iptables works is [http://www.frozentux.net/iptables-tutorial/images/tables_traverse.jpg this chart]. The lowercase word on top is the table and the upper case word below is the chain. Every IP packet that that comes in ''on any network interface'' passes through this flow chart from top to bottom. A common source of confusion is that packets entering from, say, an internal interface are handled differently than packets from an Internet-facing interface. All interfaces are handled the same way; it's up to you to define rules that treat them differently. Of course some packets are intended for local processes, hence come in from the top of the chart and stop at <Local Process>, while other packets are generated by local processes; hence start at <Local Process> and proceed downward through the flowchart. A detailed explanation of how this flow chart works can be found [http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES here].<br />
<br />
In the vast majority of use cases you won't need to use the '''raw''', '''mangle''', or '''security''' tables at all. Consequently, the following chart depicts a simplified network packet flow through ''iptables'':<br />
<br />
{{bc|<nowiki><br />
XXXXXXXXXXXXXXXXXX<br />
XXX Network XXX<br />
XXXXXXXXXXXXXXXXXX<br />
+<br />
|<br />
v<br />
+-------------+ +------------------+<br />
|table: filter| <---+ | table: nat |<br />
|chain: INPUT | | | chain: PREROUTING|<br />
+-----+-------+ | +--------+---------+<br />
| | |<br />
v | v<br />
[local process] | **************** +--------------+<br />
| +---------+ Routing decision +------> |table: filter |<br />
v **************** |chain: FORWARD|<br />
**************** +------+-------+<br />
Routing decision |<br />
**************** |<br />
| |<br />
v **************** |<br />
+-------------+ +------> Routing decision <---------------+<br />
|table: nat | | ****************<br />
|chain: OUTPUT| | +<br />
+-----+-------+ | |<br />
| | v<br />
v | +-------------------+<br />
+--------------+ | | table: nat |<br />
|table: filter | +----+ | chain: POSTROUTING|<br />
|chain: OUTPUT | +--------+----------+<br />
+--------------+ |<br />
v<br />
XXXXXXXXXXXXXXXXXX<br />
XXX Network XXX<br />
XXXXXXXXXXXXXXXXXX<br />
</nowiki>}}<br />
<br />
=== Tables ===<br />
<br />
iptables contains five tables:<br />
<br />
# {{ic|raw}} is used only for configuring packets so that they are exempt from connection tracking.<br />
# {{ic|filter}} is the default table, and is where all the actions typically associated with a firewall take place.<br />
# {{ic|nat}} is used for [[Wikipedia:Network address translation|network address translation]] (e.g. port forwarding).<br />
# {{ic|mangle}} is used for specialized packet alterations (see [[Wikipedia:Mangled packet|Mangled packet]]).<br />
# {{ic|security}} is used for [[Security#Mandatory access control|Mandatory Access Control]] networking rules (e.g. SELinux -- see [http://lwn.net/Articles/267140/ this article] for more details).<br />
<br />
In most common use cases you will only use two of these: '''filter''' and '''nat'''. The other tables are aimed at complex configurations involving multiple routers and routing decisions and are in any case beyond the scope of these introductory remarks.<br />
<br />
=== Chains ===<br />
<br />
Tables consist of ''chains'', which are lists of rules which are followed in order. The default table, {{ic|filter}}, contains three built-in chains: {{ic|INPUT}}, {{ic|OUTPUT}} and {{ic|FORWARD}} which are activated at different points of the packet filtering process, as illustrated in the [http://www.frozentux.net/iptables-tutorial/chunkyhtml/images/tables_traverse.jpg Andreasson flow chart]. The nat table includes {{ic|PREROUTING}}, {{ic|POSTROUTING}}, and {{ic|OUTPUT}} chains.<br />
<br />
See {{ic|man 8 iptables}} for a description of built-in chains in other tables.<br />
<br />
By default, none of the chains contain any rules. It is up to you to append rules to the chains that you want to use. Chains ''do'' have a default policy, which is generally set to {{ic|ACCEPT}}, but can be reset to {{ic|DROP}}, if you want to be sure that nothing slips through your ruleset. The default policy always applies at the end of a chain only. Hence, the packet has to pass through all existing rules in the chain before the default policy is applied.<br />
<br />
User-defined chains can be added to make rulesets more efficient or more easily modifiable. See [[Simple stateful firewall]] for an example of how user-defined chains are used.<br />
<br />
=== Rules ===<br />
<br />
Packet filtering is based on ''rules'', which are specified by multiple ''matches'' (conditions the packet must satisfy so that the rule can be applied), and one ''target'' (action taken when the packet matches all conditions). The typical things a rule might match on are what interface the packet came in on (e.g eth0 or eth1), what type of packet it is (ICMP, TCP, or UDP), or the destination port of the packet.<br />
<br />
Targets are specified using the {{ic|-j}} or {{ic|--jump}} option. Targets can be either user-defined chains (i.e. if these conditions are matched, jump to the following user-defined chain and continue processing there, one of the special built-in targets, or a target extension. Built-in targets are {{ic|ACCEPT}}, {{ic|DROP}}, {{ic|QUEUE}} and {{ic|RETURN}}, target extensions are, for example, {{ic|REJECT}} and {{ic|LOG}}. If the target is a built-in target, the fate of the packet is decided immediately and processing of the packet in current table is stopped. If the target is a user-defined chain and the packet passes successfully through this second chain, it will move to the next rule in the original chain. Target extensions can be either ''terminating'' (as built-in targets) or ''non-terminating'' (as user-defined chains), see {{ic|man 8 iptables-extensions}} for details.<br />
<br />
=== Traversing Chains ===<br />
<br />
A network packet received on any interface traverses the traffic control tables.chains in the order shown in the [http://www.frozentux.net/iptables-tutorial/chunkyhtml/images/tables_traverse.jpg Andreasson flow chart]. The first routing decision involves deciding if the final destination of the packet is the local machine (in which case the packet traverses through the INPUT chains) or elsewhere (in which case the packet traverses through the FORWARD chains). Subseqeunt routing decisions involve deciding what interface to assign to an outgoing packet. At each chain in the path, every rule in that chain is evaluated in order and whenever a rule matches, the corresponding target/jump action is executed. The 3 most commonly used targets are {{ic|ACCEPT}}, {{ic|DROP}}, and jump to a user-defined chain. While built-in chains can have default policies, user-defined chains can not. If every rule in a chain that you jumped to fails to provide a complete match, the packet is dropped back into the calling chain as illustrated [http://www.frozentux.net/iptables-tutorial/images/table_subtraverse.jpg here]. If at any time a complete match is achieved for a rule with a {{ic|DROP}} target, the packet is dropped and no further processing is done. If a packet is ACCEPTed within a chain, it will be ACCEPT'ed in all superset chains also and it will not traverse any of the superset chains any further. However, be aware that the packet will continue to traverse all other chains in other tables in the normal fashion.<br />
<br />
=== Modules ===<br />
<br />
There are many modules which can be used to extend iptables such as connlimit, conntrack, limit and recent. These modules add extra functionality to allow complex filtering rules.<br />
<br />
== Configuring and Running iptables ==<br />
<br />
iptables is a [[Systemd]] service and is started accordingly:<br />
<br />
# systemctl start iptables<br />
<br />
However, the service won't start unless it finds an {{ic|/etc/iptables/iptables.rules}} file, and the Arch {{Pkg|iptables}} package does not come with a default iptables.rule file. So to start the service for the first time:<br />
<br />
# touch /etc/iptables/iptables.rules<br />
# systemctl start iptables<br />
<br />
or <br />
<br />
# cp /etc/iptables/empty.rules /etc/iptables/iptables.rules<br />
# systemctl start iptables<br />
<br />
As with other services, if you want iptables to be loaded automatically on boot, you must enable it:<br />
<br />
# systemctl enable iptables<br />
<br />
=== From the command line ===<br />
<br />
<br />
==== Showing the current rules ====<br />
<br />
You can check the current ruleset and the number of hits per rule by using the command:<br />
<br />
{{hc|# iptables -nvL|Chain INPUT (policy ACCEPT 0 packets, 0 bytes)<br />
pkts bytes target prot opt in out source destination <br />
<br />
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)<br />
pkts bytes target prot opt in out source destination <br />
<br />
Chain OUTPUT (policy ACCEPT 0K packets, 0 bytes)<br />
pkts bytes target prot opt in out source destination}}<br />
<br />
If the output looks like the above, then there are no rules. Nothing is blocked.<br />
<br />
To show the line numbers when listing rules, append {{ic|--line-numbers}} to that input. This is useful when deleting and adding individual rules.<br />
<br />
==== Resetting rules ====<br />
<br />
You can flush and reset iptables to default using these commands:<br />
<br />
# iptables -F<br />
# iptables -X<br />
# iptables -t nat -F<br />
# iptables -t nat -X<br />
# iptables -t mangle -F<br />
# iptables -t mangle -X<br />
# iptables -t raw -F<br />
# iptables -t raw -X<br />
# iptables -t security -F<br />
# iptables -t security -X<br />
# iptables -P INPUT ACCEPT<br />
# iptables -P FORWARD ACCEPT<br />
# iptables -P OUTPUT ACCEPT<br />
<br />
The {{ic|-F}} command with no arguments flushes all the chains in its current table. Similarly, {{ic|-X}} deletes all empty non-default chains in a table.<br />
<br />
Individual chains may be flushed or deleted by following {{ic|-F}} and {{ic|-X}} with a {{ic|[chain]}} argument.<br />
<br />
==== Editing rules ====<br />
<br />
Rules can be added either by appending a rule to a chain or inserting them at a specific position on the chain. We will explore both methods here.<br />
<br />
First of all, our computer is not a router (unless, of course, it [[Router|is a router]]). We want to change the default policy on the {{ic|FORWARD}} chain from {{ic|ACCEPT}} to {{ic|DROP}}.<br />
<br />
{{bc|<br />
# iptables -P FORWARD DROP<br />
}}<br />
<br />
{{warning|The rest of this section is meant to teach the syntax and concepts behind iptables rules. It is not intended as a means for securing servers. For improving the security of your system, see [[Simple stateful firewall]] for a minimally secure iptables configuration and [[Security]] for hardening Arch Linux in general.}}<br />
<br />
The [[Wikipedia:Dropbox (service)|Dropbox]] LAN sync feature [https://isc.sans.edu/port.html?port=17500 broadcasts packets every 30 seconds] to all computers it can see. If we happen to be on a LAN with Dropbox clients and do not use this feature, then we might wish to reject those packets. <br />
<br />
{{bc|<br />
# iptables -A INPUT -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable<br />
}}<br />
<br />
{{hc|<br />
# iptables -nvL --line-numbers<br />
|<br />
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
1 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable<br />
<br />
Chain FORWARD (policy DROP 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
<br />
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
<br />
}}<br />
{{note|We use {{ic|REJECT}} rather than {{ic|DROP}} here, because [https://tools.ietf.org/html/rfc1122#page-69 RFC 1122 3.3.8] requires hosts return ICMP errors whenever possible, instead of dropping packets. In reality, it is best to {{ic|REJECT}} packets from hosts who should know about your server's existence, and {{ic|DROP}} packets from hosts who should not even know your server exists, or those who appear "up to something".}}<br />
<br />
Now, say we change our mind about Dropbox and decide to install it on our computer. We also want to LAN sync, but only with one particular IP on our network. So we should use {{ic|-R}} to replace our old rule. Where {{ic|10.0.0.85}} is our other IP:<br />
<br />
{{bc|<br />
# iptables -R INPUT 1 -p tcp --dport 17500 ! -s 10.0.0.85 -j REJECT --reject-with icmp-port-unreachable<br />
}}<br />
<br />
{{hc|<br />
# iptables -nvL --line-numbers<br />
|<br />
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
1 0 0 REJECT tcp -- * * !10.0.0.85 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable<br />
<br />
Chain FORWARD (policy DROP 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
<br />
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
}}<br />
<br />
We have now replaced our original rule with one that allows {{ic|10.0.0.85}} to access port {{ic|17500}} on our computer. But now we realize that this is not scalable. If our friendly Dropbox user is attempting to access port {{ic|17500}} on our device, we should allow him immediately, not test him against any firewall rules that might come afterwards!<br />
<br />
So we write a new rule to allow our trusted user immediately. Using {{ic|-I}} to insert the new rule before our old one:<br />
<br />
{{bc|<br />
# iptables -I INPUT 1 -p tcp --dport 17500 -s 10.0.0.85 -j ACCEPT -m comment --comment "Friendly Dropbox"<br />
}}<br />
<br />
{{hc|<br />
# iptables -nvL --line-numbers<br />
|<br />
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
1 0 0 ACCEPT tcp -- * * 10.0.0.85 0.0.0.0/0 tcp dpt:17500 /* Friendly Dropbox */<br />
2 0 0 REJECT tcp -- * * !10.0.0.85 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable<br />
<br />
Chain FORWARD (policy DROP 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
<br />
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
}}<br />
<br />
And replace our second rule with one that rejects everything on port {{ic|17500}}:<br />
<br />
# iptables -R INPUT 2 -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable <br />
<br />
Our final rule list now looks like this:<br />
<br />
{{hc|<br />
# iptables -nvL --line-numbers<br />
|<br />
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
1 0 0 ACCEPT tcp -- * * 10.0.0.85 0.0.0.0/0 tcp dpt:17500 /* Friendly Dropbox */<br />
2 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable<br />
<br />
Chain FORWARD (policy DROP 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
<br />
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
}}<br />
<br />
=== Configuration file ===<br />
<br />
Iptables rules are, by default in Arch Linux, stored in {{ic|/etc/iptables/iptables.rules}}. They are, however, not loaded automatically, instead you can enable the {{ic|iptables.service}} which reads this file and loads the rules at boot or when started:<br />
<br />
# systemctl enable iptables<br />
# systemctl start iptables<br />
<br />
Iptables rules for IPv6 are, by default, stored in {{ic|/etc/iptables/ip6tables.rules}}, this file is read by {{ic|ip6tables.service}}. You can start it the same way as above.<br />
<br />
After adding rules via command-line, the configuration file is not changed automatically &mdash; you have to save it manually:<br />
<br />
# iptables-save > /etc/iptables/iptables.rules<br />
<br />
If you edit the configuration file manually, you have to reload it:<br />
<br />
# systemctl reload iptables<br />
<br />
Or you can load it directly through iptables:<br />
<br />
# iptables-restore < /etc/iptables/iptables.rules<br />
<br />
=== Guides ===<br />
<br />
* [[Simple stateful firewall]]<br />
* [[Router]]<br />
<br />
== Logging ==<br />
<br />
The {{ic|LOG}} target can be used to log packets that hit a rule. Unlike other targets like {{ic|ACCEPT}} or {{ic|DROP}}, the packet will continue moving through the chain after hitting a {{ic|LOG}} target. This means that in order to enable logging for all dropped packets, you would have to add a duplicate {{ic|LOG}} rule before each DROP rule. Since this reduces efficiency and makes things less simple, a {{ic|logdrop}} chain can be created instead.<br />
<br />
Create the chain with:<br />
<br />
# iptables -N logdrop<br />
<br />
Then define it:<br />
<br />
## /etc/iptables/iptables.rules<br />
<br />
*filter<br />
:INPUT DROP [0:0]<br />
:FORWARD DROP [0:0]<br />
:OUTPUT ACCEPT [0:0]<br />
<br />
... other user defined chains ..<br />
<br />
## logdrop chain<br />
:logdrop - [0:0]<br />
<br />
-A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG<br />
-A logdrop -j DROP<br />
<br />
... rules ...<br />
<br />
## log AND drop packets that hit this rule:<br />
-A INPUT -m conntrack --ctstate INVALID -j logdrop<br />
<br />
... more rules ...<br />
<br />
=== Limiting log rate ===<br />
<br />
The limit module should be used to prevent your iptables log from growing too large or causing needless hard drive writes. Without limiting, an attacker could fill your drive (or at least your {{ic|/var}} partition) by causing writes to the iptables log.<br />
<br />
{{ic|-m limit}} is used to call on the limit module. You can then use {{ic|--limit}} to set an average rate and {{ic|--limit-burst}} to set an initial burst rate. Example:<br />
<br />
-A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG<br />
<br />
This appends a rule to the {{ic|logdrop}} chain which will log all packets that pass through it. The first 10 packets will the be logged, and from then on only 5 packets per minute will be logged. The "limit burst" is restored by one every time the "limit rate" is not broken.<br />
<br />
=== Viewing logged packets ===<br />
<br />
Logged packets are visible as kernel messages in the [[systemd#Journal|systemd journal]].<br />
<br />
To view all packets that where logged since the machine was last booted:<br />
# journalctl -k | grep "IN=.*OUT=.*" | less<br />
<br />
=== syslog-ng ===<br />
<br />
Assuming you are using [[syslog-ng]], you can control where iptables' log output goes this way:<br />
filter f_everything { level(debug..emerg) and not facility(auth, authpriv); };<br />
to<br />
filter f_everything { level(debug..emerg) and not facility(auth, authpriv) and not filter(f_iptables); };<br />
<br />
This will stop logging iptables output to {{ic|/var/log/everything.log}}.<br />
<br />
If you also want iptables to log to a different file than {{ic|/var/log/iptables.log}}, you can simply change the file value of destination {{ic|d_iptables}} here (still in {{ic|syslog-ng.conf}})<br />
destination d_iptables { file("/var/log/iptables.log"); };<br />
<br />
=== ulogd ===<br />
<br />
[http://www.netfilter.org/projects/ulogd/index.html ulogd] is a specialized userspace packet logging daemon for netfilter that can replace the default {{ic|LOG}} target. The package {{Pkg|ulogd}} is available in the {{ic|[community]}} repository.<br />
<br />
== See also ==<br />
{{Wikipedia|iptables}}<br />
* [[Port Knocking]]<br />
* [http://www.netfilter.org/projects/iptables/index.html Official iptables web site]<br />
* [http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html iptables Tutorial 1.2.2] by Oskar Andreasson<br />
* [http://wiki.debian.org/iptables iptables Debian] Debian wiki</div>Bwidhttps://wiki.archlinux.org/index.php?title=Iptables&diff=330522Iptables2014-08-16T08:58:02Z<p>Bwid: /* Logging */ journalctl example</p>
<hr />
<div>{{DISPLAYTITLE:iptables}}<br />
[[Category:Firewalls]]<br />
[[es:Iptables]]<br />
[[fr:Iptables]]<br />
[[it:Iptables]]<br />
[[ru:Iptables]]<br />
[[sr:Iptables]]<br />
[[zh-CN:Iptables]]<br />
{{Related articles start}}<br />
{{Related|Firewalls}}<br />
{{Related|Simple stateful firewall}}<br />
{{Related|Sysctl#TCP/IP stack hardening}}<br />
{{Related|Sshguard}}<br />
{{Related|Fail2ban}}<br />
{{Related|Nftables}}<br />
{{Related articles end}}<br />
<br />
Iptables is a powerful [[firewall]] built into the Linux kernel and is part of the [[Wikipedia:Netfilter|netfilter]] project. It can be configured directly, or by using one of the many [[Firewalls#iptables_front-ends|frontends]] and [[Firewall#iptables_GUIs|GUIs]]. iptables is used for [[Wikipedia:IPv4|IPv4]] and ip6tables is used for [[IPv6]].<br />
<br />
[[nftables]] was released in [http://www.phoronix.com/scan.php?page=news_item&px=MTQ5MDU release with Linux kernel 3.13], and will one day replace iptables as the main Linux firewall utility.<br />
<br />
== Installation ==<br />
<br />
The stock Arch Linux kernel is compiled with iptables support. You will only need to [[pacman|install]] the userland utilities, which are provided by the package {{Pkg|iptables}} in the [[official repositories]]. (The {{Pkg|iproute2}} package from the {{Grp|base}} group depends on iptables, so the iptables package should be installed on your system by default.)<br />
<br />
== Basic concepts ==<br />
<br />
iptables is used to inspect, modify, forward, redirect, and/or drop IPv4 packets. The code for filtering IPv4 packets is already built into the kernel and is organized into a collection of ''tables'', each with a specific purpose. The tables are made up of a set of predefined ''chains'', and the chains contain rules which are traversed in order. Each rule consists of a predicate of potential matches and a corresponding action (called a ''target'') which is executed if the predicate is true; i.e. the conditions are matched. iptables is the user utility which allow you to work with these chains/rules. Most new users find the complexities of linux IP routing quite daunting, but, in practice, the most common use cases (NAT and/or basic Internet firewall) are considerably less complex.<br />
<br />
The key to understanding how iptables works is [http://www.frozentux.net/iptables-tutorial/images/tables_traverse.jpg this chart]. The lowercase word on top is the table and the upper case word below is the chain. Every IP packet that that comes in ''on any network interface'' passes through this flow chart from top to bottom. A common source of confusion is that packets entering from, say, an internal interface are handled differently than packets from an Internet-facing interface. All interfaces are handled the same way; it's up to you to define rules that treat them differently. Of course some packets are intended for local processes, hence come in from the top of the chart and stop at <Local Process>, while other packets are generated by local processes; hence start at <Local Process> and proceed downward through the flowchart. A detailed explanation of how this flow chart works can be found [http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES here].<br />
<br />
In the vast majority of use cases you won't need to use the '''raw''', '''mangle''', or '''security''' tables at all. Consequently, the following chart depicts a simplified network packet flow through ''iptables'':<br />
<br />
{{bc|<nowiki><br />
XXXXXXXXXXXXXXXXXX<br />
XXX Network XXX<br />
XXXXXXXXXXXXXXXXXX<br />
+<br />
|<br />
v<br />
+-------------+ +------------------+<br />
|table: filter| <---+ | table: nat |<br />
|chain: INPUT | | | chain: PREROUTING|<br />
+-----+-------+ | +--------+---------+<br />
| | |<br />
v | v<br />
[local process] | **************** +--------------+<br />
| +---------+ Routing decision +------> |table: filter |<br />
v **************** |chain: FORWARD|<br />
**************** +------+-------+<br />
Routing decision |<br />
**************** |<br />
| |<br />
v **************** |<br />
+-------------+ +------> Routing decision <---------------+<br />
|table: nat | | ****************<br />
|chain: OUTPUT| | +<br />
+-----+-------+ | |<br />
| | v<br />
v | +-------------------+<br />
+--------------+ | | table: nat |<br />
|table: filter | +----+ | chain: POSTROUTING|<br />
|chain: OUTPUT | +--------+----------+<br />
+--------------+ |<br />
v<br />
XXXXXXXXXXXXXXXXXX<br />
XXX Network XXX<br />
XXXXXXXXXXXXXXXXXX<br />
</nowiki>}}<br />
<br />
=== Tables ===<br />
<br />
iptables contains five tables:<br />
<br />
# {{ic|raw}} is used only for configuring packets so that they are exempt from connection tracking.<br />
# {{ic|filter}} is the default table, and is where all the actions typically associated with a firewall take place.<br />
# {{ic|nat}} is used for [[Wikipedia:Network address translation|network address translation]] (e.g. port forwarding).<br />
# {{ic|mangle}} is used for specialized packet alterations (see [[Wikipedia:Mangled packet|Mangled packet]]).<br />
# {{ic|security}} is used for [[Security#Mandatory access control|Mandatory Access Control]] networking rules (e.g. SELinux -- see [http://lwn.net/Articles/267140/ this article] for more details).<br />
<br />
In most common use cases you will only use two of these: '''filter''' and '''nat'''. The other tables are aimed at complex configurations involving multiple routers and routing decisions and are in any case beyond the scope of these introductory remarks.<br />
<br />
=== Chains ===<br />
<br />
Tables consist of ''chains'', which are lists of rules which are followed in order. The default table, {{ic|filter}}, contains three built-in chains: {{ic|INPUT}}, {{ic|OUTPUT}} and {{ic|FORWARD}} which are activated at different points of the packet filtering process, as illustrated in the [http://www.frozentux.net/iptables-tutorial/chunkyhtml/images/tables_traverse.jpg Andreasson flow chart]. The nat table includes {{ic|PREROUTING}}, {{ic|POSTROUTING}}, and {{ic|OUTPUT}} chains.<br />
<br />
See {{ic|man 8 iptables}} for a description of built-in chains in other tables.<br />
<br />
By default, none of the chains contain any rules. It is up to you to append rules to the chains that you want to use. Chains ''do'' have a default policy, which is generally set to {{ic|ACCEPT}}, but can be reset to {{ic|DROP}}, if you want to be sure that nothing slips through your ruleset. The default policy always applies at the end of a chain only. Hence, the packet has to pass through all existing rules in the chain before the default policy is applied.<br />
<br />
User-defined chains can be added to make rulesets more efficient or more easily modifiable. See [[Simple stateful firewall]] for an example of how user-defined chains are used.<br />
<br />
=== Rules ===<br />
<br />
Packet filtering is based on ''rules'', which are specified by multiple ''matches'' (conditions the packet must satisfy so that the rule can be applied), and one ''target'' (action taken when the packet matches all conditions). The typical things a rule might match on are what interface the packet came in on (e.g eth0 or eth1), what type of packet it is (ICMP, TCP, or UDP), or the destination port of the packet.<br />
<br />
Targets are specified using the {{ic|-j}} or {{ic|--jump}} option. Targets can be either user-defined chains (i.e. if these conditions are matched, jump to the following user-defined chain and continue processing there, one of the special built-in targets, or a target extension. Built-in targets are {{ic|ACCEPT}}, {{ic|DROP}}, {{ic|QUEUE}} and {{ic|RETURN}}, target extensions are, for example, {{ic|REJECT}} and {{ic|LOG}}. If the target is a built-in target, the fate of the packet is decided immediately and processing of the packet in current table is stopped. If the target is a user-defined chain and the packet passes successfully through this second chain, it will move to the next rule in the original chain. Target extensions can be either ''terminating'' (as built-in targets) or ''non-terminating'' (as user-defined chains), see {{ic|man 8 iptables-extensions}} for details.<br />
<br />
=== Traversing Chains ===<br />
<br />
A network packet received on any interface traverses the traffic control tables.chains in the order shown in the [http://www.frozentux.net/iptables-tutorial/chunkyhtml/images/tables_traverse.jpg Andreasson flow chart]. The first routing decision involves deciding if the final destination of the packet is the local machine (in which case the packet traverses through the INPUT chains) or elsewhere (in which case the packet traverses through the FORWARD chains). Subseqeunt routing decisions involve deciding what interface to assign to an outgoing packet. At each chain in the path, every rule in that chain is evaluated in order and whenever a rule matches, the corresponding target/jump action is executed. The 3 most commonly used targets are {{ic|ACCEPT}}, {{ic|DROP}}, and jump to a user-defined chain. While built-in chains can have default policies, user-defined chains can not. If every rule in a chain that you jumped to fails to provide a complete match, the packet is dropped back into the calling chain as illustrated [http://www.frozentux.net/iptables-tutorial/images/table_subtraverse.jpg here]. If at any time a complete match is achieved for a rule with a {{ic|DROP}} target, the packet is dropped and no further processing is done. If a packet is ACCEPTed within a chain, it will be ACCEPT'ed in all superset chains also and it will not traverse any of the superset chains any further. However, be aware that the packet will continue to traverse all other chains in other tables in the normal fashion.<br />
<br />
=== Modules ===<br />
<br />
There are many modules which can be used to extend iptables such as connlimit, conntrack, limit and recent. These modules add extra functionality to allow complex filtering rules.<br />
<br />
== Configuring and Running iptables ==<br />
<br />
iptables is a [[Systemd]] service and is started accordingly:<br />
<br />
# systemctl start iptables<br />
<br />
However, the service won't start unless it finds an {{ic|/etc/iptables/iptables.rules}} file, and the Arch {{Pkg|iptables}} package does not come with a default iptables.rule file. So to start the service for the first time:<br />
<br />
# touch /etc/iptables/iptables.rules<br />
# systemctl start iptables<br />
<br />
or <br />
<br />
# cp /etc/iptables/empty.rules /etc/iptables/iptables.rules<br />
# systemctl start iptables<br />
<br />
As with other services, if you want iptables to be loaded automatically on boot, you must enable it:<br />
<br />
# systemctl enable iptables<br />
<br />
=== From the command line ===<br />
<br />
<br />
==== Showing the current rules ====<br />
<br />
You can check the current ruleset and the number of hits per rule by using the command:<br />
<br />
{{hc|# iptables -nvL|Chain INPUT (policy ACCEPT 0 packets, 0 bytes)<br />
pkts bytes target prot opt in out source destination <br />
<br />
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)<br />
pkts bytes target prot opt in out source destination <br />
<br />
Chain OUTPUT (policy ACCEPT 0K packets, 0 bytes)<br />
pkts bytes target prot opt in out source destination}}<br />
<br />
If the output looks like the above, then there are no rules. Nothing is blocked.<br />
<br />
To show the line numbers when listing rules, append {{ic|--line-numbers}} to that input. This is useful when deleting and adding individual rules.<br />
<br />
==== Resetting rules ====<br />
<br />
You can flush and reset iptables to default using these commands:<br />
<br />
# iptables -F<br />
# iptables -X<br />
# iptables -t nat -F<br />
# iptables -t nat -X<br />
# iptables -t mangle -F<br />
# iptables -t mangle -X<br />
# iptables -t raw -F<br />
# iptables -t raw -X<br />
# iptables -t security -F<br />
# iptables -t security -X<br />
# iptables -P INPUT ACCEPT<br />
# iptables -P FORWARD ACCEPT<br />
# iptables -P OUTPUT ACCEPT<br />
<br />
The {{ic|-F}} command with no arguments flushes all the chains in its current table. Similarly, {{ic|-X}} deletes all empty non-default chains in a table.<br />
<br />
Individual chains may be flushed or deleted by following {{ic|-F}} and {{ic|-X}} with a {{ic|[chain]}} argument.<br />
<br />
==== Editing rules ====<br />
<br />
Rules can be added either by appending a rule to a chain or inserting them at a specific position on the chain. We will explore both methods here.<br />
<br />
First of all, our computer is not a router (unless, of course, it [[Router|is a router]]). We want to change the default policy on the {{ic|FORWARD}} chain from {{ic|ACCEPT}} to {{ic|DROP}}.<br />
<br />
{{bc|<br />
# iptables -P FORWARD DROP<br />
}}<br />
<br />
{{warning|The rest of this section is meant to teach the syntax and concepts behind iptables rules. It is not intended as a means for securing servers. For improving the security of your system, see [[Simple stateful firewall]] for a minimally secure iptables configuration and [[Security]] for hardening Arch Linux in general.}}<br />
<br />
The [[Wikipedia:Dropbox (service)|Dropbox]] LAN sync feature [https://isc.sans.edu/port.html?port=17500 broadcasts packets every 30 seconds] to all computers it can see. If we happen to be on a LAN with Dropbox clients and do not use this feature, then we might wish to reject those packets. <br />
<br />
{{bc|<br />
# iptables -A INPUT -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable<br />
}}<br />
<br />
{{hc|<br />
# iptables -nvL --line-numbers<br />
|<br />
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
1 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable<br />
<br />
Chain FORWARD (policy DROP 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
<br />
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
<br />
}}<br />
{{note|We use {{ic|REJECT}} rather than {{ic|DROP}} here, because [https://tools.ietf.org/html/rfc1122#page-69 RFC 1122 3.3.8] requires hosts return ICMP errors whenever possible, instead of dropping packets. In reality, it is best to {{ic|REJECT}} packets from hosts who should know about your server's existence, and {{ic|DROP}} packets from hosts who should not even know your server exists, or those who appear "up to something".}}<br />
<br />
Now, say we change our mind about Dropbox and decide to install it on our computer. We also want to LAN sync, but only with one particular IP on our network. So we should use {{ic|-R}} to replace our old rule. Where {{ic|10.0.0.85}} is our other IP:<br />
<br />
{{bc|<br />
# iptables -R INPUT 1 -p tcp --dport 17500 ! -s 10.0.0.85 -j REJECT --reject-with icmp-port-unreachable<br />
}}<br />
<br />
{{hc|<br />
# iptables -nvL --line-numbers<br />
|<br />
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
1 0 0 REJECT tcp -- * * !10.0.0.85 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable<br />
<br />
Chain FORWARD (policy DROP 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
<br />
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
}}<br />
<br />
We have now replaced our original rule with one that allows {{ic|10.0.0.85}} to access port {{ic|17500}} on our computer. But now we realize that this is not scalable. If our friendly Dropbox user is attempting to access port {{ic|17500}} on our device, we should allow him immediately, not test him against any firewall rules that might come afterwards!<br />
<br />
So we write a new rule to allow our trusted user immediately. Using {{ic|-I}} to insert the new rule before our old one:<br />
<br />
{{bc|<br />
# iptables -I INPUT 1 -p tcp --dport 17500 -s 10.0.0.85 -j ACCEPT -m comment --comment "Friendly Dropbox"<br />
}}<br />
<br />
{{hc|<br />
# iptables -nvL --line-numbers<br />
|<br />
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
1 0 0 ACCEPT tcp -- * * 10.0.0.85 0.0.0.0/0 tcp dpt:17500 /* Friendly Dropbox */<br />
2 0 0 REJECT tcp -- * * !10.0.0.85 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable<br />
<br />
Chain FORWARD (policy DROP 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
<br />
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
}}<br />
<br />
And replace our second rule with one that rejects everything on port {{ic|17500}}:<br />
<br />
# iptables -R INPUT 2 -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable <br />
<br />
Our final rule list now looks like this:<br />
<br />
{{hc|<br />
# iptables -nvL --line-numbers<br />
|<br />
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
1 0 0 ACCEPT tcp -- * * 10.0.0.85 0.0.0.0/0 tcp dpt:17500 /* Friendly Dropbox */<br />
2 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:17500 reject-with icmp-port-unreachable<br />
<br />
Chain FORWARD (policy DROP 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
<br />
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination <br />
}}<br />
<br />
=== Configuration file ===<br />
<br />
Iptables rules are, by default in Arch Linux, stored in {{ic|/etc/iptables/iptables.rules}}. They are, however, not loaded automatically, instead you can enable the {{ic|iptables.service}} which reads this file and loads the rules at boot or when started:<br />
<br />
# systemctl enable iptables<br />
# systemctl start iptables<br />
<br />
Iptables rules for IPv6 are, by default, stored in {{ic|/etc/iptables/ip6tables.rules}}, this file is read by {{ic|ip6tables.service}}. You can start it the same way as above.<br />
<br />
After adding rules via command-line, the configuration file is not changed automatically &mdash; you have to save it manually:<br />
<br />
# iptables-save > /etc/iptables/iptables.rules<br />
<br />
If you edit the configuration file manually, you have to reload it:<br />
<br />
# systemctl reload iptables<br />
<br />
Or you can load it directly through iptables:<br />
<br />
# iptables-restore < /etc/iptables/iptables.rules<br />
<br />
=== Guides ===<br />
<br />
* [[Simple stateful firewall]]<br />
* [[Router]]<br />
<br />
== Logging ==<br />
<br />
The {{ic|LOG}} target can be used to log packets that hit a rule. Unlike other targets like {{ic|ACCEPT}} or {{ic|DROP}}, the packet will continue moving through the chain after hitting a {{ic|LOG}} target. This means that in order to enable logging for all dropped packets, you would have to add a duplicate {{ic|LOG}} rule before each DROP rule. Since this reduces efficiency and makes things less simple, a {{ic|logdrop}} chain can be created instead.<br />
<br />
Create the chain with:<br />
<br />
# iptables -N logdrop<br />
<br />
Then define it:<br />
<br />
## /etc/iptables/iptables.rules<br />
<br />
*filter<br />
:INPUT DROP [0:0]<br />
:FORWARD DROP [0:0]<br />
:OUTPUT ACCEPT [0:0]<br />
<br />
... other user defined chains ..<br />
<br />
## logdrop chain<br />
:logdrop - [0:0]<br />
<br />
-A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG<br />
-A logdrop -j DROP<br />
<br />
... rules ...<br />
<br />
## log AND drop packets that hit this rule:<br />
-A INPUT -m conntrack --ctstate INVALID -j logdrop<br />
<br />
... more rules ...<br />
<br />
=== Limiting log rate ===<br />
<br />
The limit module should be used to prevent your iptables log from growing too large or causing needless hard drive writes. Without limiting, an attacker could fill your drive (or at least your {{ic|/var}} partition) by causing writes to the iptables log.<br />
<br />
{{ic|-m limit}} is used to call on the limit module. You can then use {{ic|--limit}} to set an average rate and {{ic|--limit-burst}} to set an initial burst rate. Example:<br />
<br />
-A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG<br />
<br />
This appends a rule to the {{ic|logdrop}} chain which will log all packets that pass through it. The first 10 packets will the be logged, and from then on only 5 packets per minute will be logged. The "limit burst" is restored by one every time the "limit rate" is not broken.<br />
<br />
=== Viewing logged packets ===<br />
<br />
Logged packets are visible as kernel messages in the [[systemd]] journal.<br />
<br />
To view all packets that where logged since the machine was last booted:<br />
# journalctl -k | grep "IN=.*OUT=.*" | less<br />
<br />
Refer to [[systemd#Journal]] for detailed {{ic|journalctl}} usage instructions.<br />
<br />
=== syslog-ng ===<br />
<br />
Assuming you are using [[syslog-ng]], you can control where iptables' log output goes this way:<br />
filter f_everything { level(debug..emerg) and not facility(auth, authpriv); };<br />
to<br />
filter f_everything { level(debug..emerg) and not facility(auth, authpriv) and not filter(f_iptables); };<br />
<br />
This will stop logging iptables output to {{ic|/var/log/everything.log}}.<br />
<br />
If you also want iptables to log to a different file than {{ic|/var/log/iptables.log}}, you can simply change the file value of destination {{ic|d_iptables}} here (still in {{ic|syslog-ng.conf}})<br />
destination d_iptables { file("/var/log/iptables.log"); };<br />
<br />
=== ulogd ===<br />
<br />
[http://www.netfilter.org/projects/ulogd/index.html ulogd] is a specialized userspace packet logging daemon for netfilter that can replace the default {{ic|LOG}} target. The package {{Pkg|ulogd}} is available in the {{ic|[community]}} repository.<br />
<br />
== See also ==<br />
{{Wikipedia|iptables}}<br />
* [[Port Knocking]]<br />
* [http://www.netfilter.org/projects/iptables/index.html Official iptables web site]<br />
* [http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html iptables Tutorial 1.2.2] by Oskar Andreasson<br />
* [http://wiki.debian.org/iptables iptables Debian] Debian wiki</div>Bwidhttps://wiki.archlinux.org/index.php?title=LVM&diff=326569LVM2014-07-24T14:30:28Z<p>Bwid: devicename of whole, unpartitioned disk is just sda</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[Category:File systems]]<br />
[[cs:LVM]]<br />
[[de:LVM]]<br />
[[es:LVM]]<br />
[[fr:LVM]]<br />
[[it:LVM]]<br />
[[ja:LVM]]<br />
[[ru:LVM]]<br />
[[tr:LVM]]<br />
[[zh-CN:LVM]]<br />
{{Related articles start}}<br />
{{Related|Software RAID and LVM}}<br />
{{Related|dm-crypt/Encrypting an entire system#LVM on LUKS}}<br />
{{Related|dm-crypt/Encrypting an entire system#LUKS on LVM}}<br />
{{Related articles end}}<br />
From [[Wikipedia:Logical Volume Manager (Linux)]]:<br />
:LVM is a [[Wikipedia:logical volume management|logical volume manager]] for the [[Wikipedia:Linux kernel|Linux kernel]]; it manages disk drives and similar mass-storage devices.<br />
<br />
=== LVM Building Blocks ===<br />
<br />
Logical Volume Management makes use of the [http://sources.redhat.com/dm/ device-mapper] feature of the Linux kernel to provide a system of partitions independent of the underlying disk's layout. With LVM you abstract your storage and have "virtual partitions", making it easier to extend and shrink partitions (subject to potential limitations of your file system) and add/remove partitions without worrying about whether you have enough contiguous space on a particular disk, getting caught up in fdisking a disk in use (and wondering whether the kernel is using the old or new partition table), or, having to move other partitions out of the way. This is strictly an ease-of-management issue: it does not provide any security. However, it sits nicely with the other two technologies we are using.<br />
<br />
The basic building blocks of LVM are:<br />
<br />
* '''Physical volume (PV)''': Partition on hard disk (or even hard disk itself or loopback file) on which you can have volume groups. It has a special header and is divided into physical extents. Think of physical volumes as big building blocks which can be used to build your hard drive.<br />
* '''Volume group (VG)''': Group of physical volumes that are used as storage volume (as one disk). They contain logical volumes. Think of volume groups as hard drives.<br />
* '''Logical volume (LV)''': A "virtual/logical partition" that resides in a volume group and is composed of physical extents. Think of logical volumes as normal partitions.<br />
* '''Physical extent (PE)''': The smallest size in the physical volume that can be assigned to a logical volume. The default is 4MiB. Think of physical extents as parts of disks that can be allocated to any partition.<br />
<br />
Example:<br />
'''Physical disks'''<br />
<br />
Disk1 (/dev/sda):<br />
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _<br />
|Partition1 50GB (Physical volume) |Partition2 80GB (Physical volume) |<br />
|/dev/sda1 |/dev/sda2 |<br />
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |<br />
<br />
Disk2 (/dev/sdb):<br />
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _<br />
|Partition1 120GB (Physical volume) |<br />
|/dev/sdb1 |<br />
| _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __ _ _|<br />
<br />
'''LVM logical volumes'''<br />
<br />
Volume Group1 (/dev/MyStorage/ = /dev/sda1 + /dev/sda2 + /dev/sdb1):<br />
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ <br />
|Logical volume1 15GB |Logical volume2 35GB |Logical volume3 200GB |<br />
|/dev/MyStorage/rootvol|/dev/MyStorage/homevol |/dev/MyStorage/mediavol |<br />
|_ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |<br />
<br />
=== Advantages ===<br />
<br />
LVM gives you more flexibility than just using normal hard drive partitions:<br />
* Use any number of disks as one big disk.<br />
* Have logical volumes stretched over several disks.<br />
* Create small logical volumes and resize them "dynamically" as they get more filled.<br />
* Resize logical volumes regardless of their order on disk. It does not depend on the position of the LV within VG, there is no need to ensure surrounding available space.<br />
* Resize/create/delete logical and physical volumes online. File systems on them still need to be resized, but some (such as ext4) support online resizing.<br />
* Online/live migration of LV being used by services to different disks without having to restart services.<br />
* Snapshots allow you to backup a frozen copy of the file system, while keeping service downtime to a minimum.<br />
* Support for various device-mapper targets, including transparent filesystem encryption and caching of frequently used data.<br />
<br />
=== Disadvantages ===<br />
<br />
* Linux exclusive (almost). There is no official support in most other OS (FreeBSD, Windows..).<br />
* Additional steps in setting up the system, more complicated.<br />
<br />
== Installing Arch Linux on LVM ==<br />
<br />
You should create your LVM Volumes between the [[partitioning]] and [[File_systems#Create a filesystem|formatting]] steps of the [[Installation guide|installation procedure]]. Instead of directly formatting a partition to be your root file system, it will be created inside a logical volume (LV). <br />
<br />
Make sure the {{pkg|lvm2}} package is [[pacman|installed]].<br />
<br />
Quick overview: <br />
* Create partition(s) where your PV will reside. Set the partition type to 'Linux LVM', which is 8e if you use MBR, 8e00 for GPT.<br />
* Create your physical volumes (PV). If you have one disk it is best to just create one PV in one large partition. If you have multiple disks you can create partitions on each of them and create a PV on each partition.<br />
* Create your volume group (VG) and add all the PV to it.<br />
* Create logical volumes (LV) inside your VG.<br />
* Continue with “Format the partitions” step of [[Beginners' guide]].<br />
* When you reach the “Create initial ramdisk environment” step in the Beginners Guide, add the {{ic|lvm}} hook to {{ic|/etc/mkinitcpio.conf}} (see below for details).<br />
<br />
{{Warning|{{ic|/boot}} cannot reside in LVM when using [[GRUB Legacy]], which does not support LVM. [[GRUB]] users do not have this limitation. If you need to use GRUB Legacy, you must create a separate {{ic|/boot}} partition and format it directly. }}<br />
<br />
=== Create partitions ===<br />
{{Note|This step is optional and depends on the users preference. In most cases it is recommended to partition the device first, though.}}<br />
See [[Partitioning]] on how to create partitions on your device.<br />
<br />
=== Create physical volumes ===<br />
To list all your devices capable of being used as a physical volume:<br />
# lvmdiskscan<br />
<br />
{{Warning|Make sure you target the correct device, or below commands will result in data loss!}}<br />
<br />
Create a physical volume on them:<br />
<br />
# pvcreate ''DEVICE''<br />
<br />
This command creates a header on each device so it can be used for LVM. As defined in [[LVM#LVM_Building_Blocks]], ''DEVICE'' can be a disk (e.g. {{ic|/dev/sda}}), a partition (e.g. {{ic|/dev/sda2}}) or a loop back device. For example: <br />
<br />
# pvcreate /dev/sda2<br />
<br />
You can track created physical volumes with:<br />
# pvdisplay<br />
<br />
{{Note|If using a SSD without partitioning it first, use {{ic|pvcreate --dataalignment 1m /dev/sda}} (for erase block size < 1MiB), see e.g. [http://serverfault.com/questions/356534/ssd-erase-block-size-lvm-pv-on-raw-device-alignment here]}}<br />
<br />
=== Create volume group ===<br />
<br />
The next step is to create a volume group on this physical volume.<br />
<br />
First you need to create a volume group on one of the physical volumes:<br />
<br />
# vgcreate <''volume_group''> <''physical_volume''><br />
<br />
For example:<br />
<br />
# vgcreate VolGroup00 /dev/sda2<br />
<br />
Then add to it all other physical volumes you want to have in it:<br />
<br />
# vgextend <''volume_group''> <''physical_volume''><br />
# vgextend <''volume_group''> <''another_physical_volume''><br />
# ...<br />
<br />
For example:<br />
<br />
# vgextend VolGroup00 /dev/sdb1<br />
# vgextend VolGroup00 /dev/sdc<br />
<br />
You can track how your volume group grows with:<br />
<br />
# vgdisplay<br />
<br />
{{Note|You can create more than one volume group if you need to, but then you will not have all your storage presented as one disk.}}<br />
<br />
=== Create in one step ===<br />
<br />
LVM allows you to combine the creation of a volume group and the physical volumes in one easy step. For example, to create the group VolGroup00 with the three devices mentioned above, you can run:<br />
<br />
# vgcreate VolGroup00 /dev/sda2 /dev/sdb1 /dev/sdc<br />
<br />
This command will first set up the three partitions as physical volumes (if necessary) and then create the volume group with the three volumes. The command will warn you it detects an existing filesystem on any of the devices.<br />
<br />
=== Create logical volumes ===<br />
<br />
Now we need to create logical volumes on this volume group. You create a logical volume with the next command by giving the name of a new logical volume, its size, and the volume group it will live on:<br />
<br />
# lvcreate -L <''size''> <''volume_group''> -n <''logical_volume''><br />
<br />
For example:<br />
<br />
# lvcreate -L 10G VolGroup00 -n lvolhome<br />
<br />
This will create a logical volume that you can access later with {{ic|/dev/mapper/Volgroup00-lvolhome}} or {{ic|/dev/VolGroup00/lvolhome}}. Same as with the volume groups, you can use any name you want for your logical volume when creating it.<br />
<br />
You can also specify one or more physical volumes to restrict where LVM allocates the data. For example, you may wish to create a logical volume for the root filesystem on your small SSD, and your home volume on a slower mechanical drive. Simply add the physical volume devices to the command line, for example:<br />
<br />
# lvcreate -L 10G VolGroup00 -n lvolhome /dev/sdc1<br />
<br />
To create swap on a logical volume, an additional argument is needed:<br />
<br />
# lvcreate -C y -L <''size''> <''volume_group''> -n <''logical_volume''><br />
<br />
The {{Ic|-C y}} is used to create a contiguous partition, which means that your swap space does not get partitioned over one or more disks nor over non-contiguous physical extents.<br />
<br />
If you want to fill all the free space left on a volume group, use the next command:<br />
<br />
# lvcreate -l +100%FREE <''volume_group''> -n <''logical_volume''><br />
<br />
You can track created logical volumes with:<br />
<br />
# lvdisplay<br />
<br />
{{Note|You may need to load the ''device-mapper'' kernel module ('''modprobe dm-mod''') for the above commands to succeed.}}<br />
<br />
{{Tip|You can start out with relatively small logical volumes and expand them later if needed. For simplicity, leave some free space in the volume group so there is room for expansion.}}<br />
<br />
=== Create file systems and mount logical volumes ===<br />
<br />
Your logical volumes should now be located in {{ic|/dev/mapper/}} and {{ic|/dev/''YourVolumeGroupName''}}. If you cannot find them, use the next commands to bring up the module for creating device nodes and to make volume groups available:<br />
<br />
# modprobe dm-mod<br />
# vgscan<br />
# vgchange -ay<br />
<br />
Now you can create file systems on logical volumes and mount them as normal partitions (if you are installing Arch linux, refer to [[Beginners' guide#Mount the partitions|mounting the partitions]] for additional details):<br />
<br />
# mkfs.<''fstype''> /dev/mapper/<''volume_group''>-<''logical_volume''><br />
# mount /dev/mapper/<''volume_group''>-<''logical_volume''> /<''mountpoint''><br />
<br />
For example:<br />
<br />
# mkfs.ext4 /dev/mapper/VolGroup00-lvolhome<br />
# mount /dev/mapper/VolGroup00-lvolhome /home<br />
<br />
{{Warning|When choosing mountpoints, just select your newly created logical volumes (use: {{ic|/dev/mapper/Volgroup00-lvolhome}}). Do '''not''' select the actual partitions on which logical volumes were created (do not use: {{ic|/dev/sda2}}).}}<br />
<br />
=== Add lvm hook to mkinitcpio.conf ===<br />
<br />
You will need to make sure the {{Ic|udev}} and {{Ic|lvm2}} [[mkinitcpio]] hooks are enabled.<br />
<br />
{{Ic|udev}} is there by default. Edit the file and insert {{Ic|lvm2}} between {{Ic|block}} and {{Ic|filesystems}} like so:<br />
<br />
{{hc|1= /etc/mkinitcpio.conf|2= HOOKS="base udev ... block '''lvm2''' filesystems"}}<br />
<br />
Afterwards, you can continue in normal installation instructions with the [[Mkinitcpio#Image_creation_and_activation|create an initial ramdisk]] step.<br />
<br />
== Configuration ==<br />
<br />
=== Advanced options ===<br />
<br />
If you need monitoring (needed for snapshots) you can enable lvmetad. <br />
For this set {{ic|1=use_lvmetad = 1}} in {{ic|/etc/lvm/lvm.conf}}.<br />
This is the default by now. <br />
<br />
You can restrict the volumes that are activated automatically by setting the {{Ic|auto_activation_volume_list}} in {{Ic|/etc/lvm/lvm.conf}}. If in doubt, leave this option commented out.<br />
<br />
=== Grow physical volume ===<br />
<br />
After changing the size of a device that has a physical volume on it, you need to grow the physical volume using the following command:<br />
<br />
# pvresize ''DEVICE''<br />
<br />
For example, to grow a physical volume located on a mdadm [[RAID]] array:<br />
<br />
# pvresize /dev/md0<br />
<br />
{{Note|This command can be done while the volume is online.}}<br />
<br />
=== Grow logical volume ===<br />
<br />
To increase the available space on a filesystem that resides on a logical volume, two steps need to be done. First grow the logical volume, and then resize the [[File systems|filesystem]] to use the newly created free space.<br />
<br />
==== lvextend ====<br />
<br />
To grow a logical volume, two different commands can be used, {{ic|lvextend}} or {{ic|lvresize}}.<br />
<br />
# lvextend -L +<''size''> <''volume_group''>/<''logical_volume''><br />
<br />
For example:<br />
<br />
# lvextend -L +20G VolGroup00/lvolhome<br />
<br />
If you want to fill all the free space on a volume group, use the following command:<br />
<br />
# lvextend -l +100%FREE <''volume_group''>/<''logical_volume''><br />
<br />
==== resize2fs ====<br />
<br />
To resize an ext2,ext3 or ext4 filesystem:<br />
<br />
# resize2fs /dev/<''volume_group''>/<''logical_volume''><br />
<br />
{{Warning|Not all file systems support growing without loss of data and/or growing online.}}<br />
<br />
{{Note|If you do not resize your filesystem, there will not be more free space available on the filesystem. The logical volume will be bigger but partly unused.}}<br />
<br />
For example:<br />
<br />
# resize2fs /dev/VolGroup00/lvolhome<br />
<br />
=== Shrink logical volume ===<br />
<br />
Because your file system is probably as big as the logical volume it resides on, you need to shrink the file system first and then shrink the logical volume. Depending on your file system, you may need to unmount it first. Let us say we have a logical volume of 15 GB with ext3 on it and we want to shrink it to 10 GB. We need to do the following steps: <br />
# resize2fs /dev/VolGroup00/lvolhome 9G<br />
# lvreduce -L 10G VolGroup00/lvolhome<br />
<br />
Here we shrunk the file system more than needed so that when we shrunk the logical volume we did not accidentally cut off the end of the file system. After that, we normally grow the file system to fill all free space left on logical volume. <br />
<br />
'''Alternatively''', you may use {{Ic|lvresize}} instead of {{Ic|lvreduce}}:<br />
# lvresize -L -5G VolGroup00/lvolhome<br />
# resize2fs /dev/VolGroup00/lvolhome<br />
<br />
{{Warning|<br />
* Do not reduce the file system size to less than the amount of space occupied by data or you risk data loss.<br />
* Not all file systems support shrinking without loss of data and/or shrinking online.<br />
}}<br />
<br />
{{Note|It is better to reduce the file system to a smaller size than the logical volume, so that after resizing the logical volume, we do not accidentally cut off some data from the end of the file system.}}<br />
<br />
=== Remove logical volume ===<br />
<br />
{{Warning|Before you remove a logical volume, make sure to move all data that you want to keep somewhere else; otherwise, it will be lost!}}<br />
<br />
First, find out the name of the logical volume you want to remove. You can get a list of all logical volumes with:<br />
<br />
# lvs<br />
<br />
Next, look up the mountpoint of the chosen logical volume:<br />
<br />
$ lsblk<br />
<br />
Then unmount the filesystem on the logical volume:<br />
<br />
# umount /<''mountpoint''><br />
<br />
Finally, remove the logical volume:<br />
<br />
# lvremove <''volume_goup''>/<''logical_volume''><br />
<br />
For example:<br />
<br />
# lvremove VolGroup00/lvolhome<br />
<br />
Confirm by typing in {{ic|y}}.<br />
<br />
Update {{ic|/etc/fstab}} as necessary.<br />
<br />
You can verify the removal of the logical volume by typing {{ic|lvs}} as root again (see first step of this section).<br />
<br />
=== Add physical volume to a volume group ===<br />
<br />
You first create a new physical volume on the block device you wish to use, then extend your volume group<br />
<br />
{{bc|1=<br />
# pvcreate /dev/sdb1<br />
# vgextend VolGroup00 /dev/sdb1<br />
}}<br />
<br />
This of course will increase the total number of physical extents on your volume group, which can be allocated by logical volumes as you see fit.<br />
<br />
{{Note|It is considered good form to have a [[Partitioning|partition table]] on your storage medium below LVM. Use the appropriate type code: {{ic|8e}} for MBR, and {{ic|8e00}} for GPT partitions.}}<br />
<br />
=== Remove partition from a volume group ===<br />
<br />
All of the data on that partition needs to be moved to another partition. Fortunately, LVM makes this easy:<br />
# pvmove /dev/sdb1<br />
If you want to have the data on a specific physical volume, specify that as the second argument to {{Ic|pvmove}}:<br />
# pvmove /dev/sdb1 /dev/sdf1<br />
Then the physical volume needs to be removed from the volume group:<br />
# vgreduce myVg /dev/sdb1<br />
Or remove all empty physical volumes:<br />
# vgreduce --all vg0<br />
<br />
And lastly, if you want to use the partition for something else, and want to avoid LVM thinking that the partition is a physical volume:<br />
# pvremove /dev/sdb1<br />
<br />
<br />
=== Deactivate volume group ===<br />
<br />
Just invoke <br />
# vgchange -a n my_volume_group<br />
<br />
This will deactivate the volume group and allow you to unmount the container it is stored in.<br />
<br />
=== Snapshots ===<br />
<br />
==== Introduction ====<br />
<br />
LVM allows you to take a snapshot of your system in a much more efficient way than a traditional backup. It does this efficiently by using a COW (copy-on-write) policy. The initial snapshot you take simply contains hard-links to the inodes of your actual data. So long as your data remains unchanged, the snapshot merely contains its inode pointers and not the data itself. Whenever you modify a file or directory that the snapshot points to, LVM automatically clones the data, the old copy referenced by the snapshot, and the new copy referenced by your active system. Thus, you can snapshot a system with 35GB of data using just 2GB of free space so long as you modify less than 2GB (on both the original and snapshot).<br />
<br />
==== Configuration ====<br />
<br />
You create snapshot logical volumes just like normal ones.<br />
<br />
# lvcreate --size 100M --snapshot --name snap01 /dev/mapper/vg0-pv<br />
With that volume, you may modify less than 100M of data, before the snapshot volume fills up.<br />
<br />
Reverting the modified 'pv' logical volume to the state when the 'snap01' snapshot was taken can be done with<br />
<br />
{{ic|# lvconvert --merge /dev/vg0/snap01}}<br />
<br />
In case the origin logical volume is active, merging will occur on the next reboot.(Merging can be done even from a LiveCD)<br />
<br />
The snapshot will no longer exist after merging.<br />
<br />
Also multiple snapshots can be taken and each one can be merged with the origin logical volume at will.<br />
<br />
The snapshot can be mounted and backed up with '''dd''' or '''tar'''. The size of the backup file done with '''dd''' will be the size of the files residing on the snapshot volume. <br />
To restore just create a snapshot, mount it, and write or extract the backup to it. And then merge it with the origin.<br />
<br />
It is important to have the ''dm_snapshot'' module listed in the MODULES variable of {{ic|/etc/mkinitcpio.conf}}, otherwise the system will not boot. If you do this on an already installed system, make sure to rebuild the image with<br />
# mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
Todo: scripts to automate snapshots of root before updates, to rollback... updating {{ic|menu.lst}} to boot snapshots (separate article?)<br />
<br />
snapshots are primarily used to provide a frozen copy of a file system to make backups; a backup taking two hours provides a more consistent image of the file system than directly backing up the partition.<br />
<br />
See [[Create root filesystem snapshots with LVM]] for automating the creation of clean root file system snapshots during system startup for backup and rollback.<br />
<br />
[[Dm-crypt/Encrypting an entire system#LVM on LUKS]] and [[Dm-crypt/Encrypting an entire system#LUKS on LVM]].<br />
<br />
If you have LVM volumes not activated via the [[Mkinitcpio|initramfs]], [[#Using units|enable]] the '''lvm-monitoring''' service, which is provided by the {{pkg|lvm2}} package.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Changes that could be required due to changes in the Arch-Linux defaults ===<br />
<br />
The {{ic|1=use_lvmetad = 1}} must be set in {{ic|/etc/lvm/lvm.conf}}. This is the default now - if you have a {{ic|lvm.conf.pacnew}} file, you must merge this change.<br />
<br />
=== LVM commands do not work ===<br />
<br />
* Load proper module:<br />
# modprobe dm_mod<br />
<br />
The {{ic|dm_mod}} module should be automatically loaded. In case it does not, you can try:<br />
{{Accuracy|Should module loading at boot be done using "/etc/modules-load.d" instead?}}<br />
<br />
{{hc|/etc/mkinitcpio.conf:|<nowiki>MODULES="dm_mod ..."</nowiki>}}<br />
<br />
You will need to [[Mkinitcpio#Image_creation_and_activation|rebuild]] the initramfs to commit any changes you made.<br />
<br />
* Try preceding commands with ''lvm'' like this:<br />
# lvm pvdisplay<br />
<br />
=== Logical Volumes do not show up ===<br />
<br />
If you are trying to mount existing logical volumes, but they do not show up in {{ic|lvscan}}, you can use the following commands to activate them:<br />
<br />
# vgscan<br />
# vgchange -ay<br />
<br />
=== LVM on removable media ===<br />
<br />
Symptoms:<br />
# vgscan<br />
Reading all physical volumes. This may take a while...<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836585984: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836643328: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 0: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 4096: Input/output error<br />
Found volume group "backupdrive1" using metadata type lvm2<br />
Found volume group "networkdrive" using metadata type lvm2<br />
<br />
Cause:<br />
:Removing an external LVM drive without deactivating the volume group(s) first. Before you disconnect, make sure to:<br />
# vgchange -an ''volume group name''<br />
<br />
Fix: assuming you already tried to activate the volume group with {{ic|# vgchange -ay ''vg''}}, and are receiving the Input/output errors:<br />
# vgchange -an ''volume group name''<br />
Unplug the external drive and wait a few minutes:<br />
# vgscan<br />
# vgchange -ay ''volume group name''<br />
<br />
=== Kernel options ===<br />
<br />
In kernel options, you may need {{ic|dolvm}}. {{ic|<nowiki>root=</nowiki>}} should be set to the logical volume, e.g {{ic|/dev/mapper/''vg-name''-''lv-name''}}.<br />
<br />
== See also ==<br />
<br />
* [http://sourceware.org/lvm2/ LVM2 Resource Page] on SourceWare.org<br />
* [http://tldp.org/HOWTO/LVM-HOWTO/ LVM HOWTO] article at The Linux Documentation project<br />
* [http://wiki.gentoo.org/wiki/LVM LVM] article at Gentoo wiki<br />
* [http://www.joshbryan.com/blog/2008/01/02/lvm2-mirrors-vs-md-raid-1/ LVM2 Mirrors vs. MD Raid 1] post by Josh Bryan<br />
* [http://www.tutonics.com/2012/11/ubuntu-lvm-guide-part-1.html Ubuntu LVM Guide Part 1][http://www.tutonics.com/2012/12/lvm-guide-part-2-snapshots.html Part 2 detals snapshots]</div>Bwidhttps://wiki.archlinux.org/index.php?title=Music_Player_Daemon&diff=309120Music Player Daemon2014-04-07T08:55:28Z<p>Bwid: /* Global configuration */ s/local/global (mpd will run as another user when following the "global" instructions, that is where the workaround is needed)</p>
<hr />
<div>[[Category:Player]]<br />
[[de:Music Player Daemon]]<br />
[[es:Music Player Daemon]]<br />
[[fr:MPD]]<br />
[[it:Music Player Daemon]]<br />
[[ja:Music Player Daemon]]<br />
[[nl:Music Player Daemon]]<br />
[[pl:Music Player Daemon]]<br />
[[ru:Music Player Daemon]]<br />
[[sr:Music Player Daemon]]<br />
[[tr:Music_Player_Daemon]]<br />
[[zh-CN:Music Player Daemon]]<br />
{{Related articles start}}<br />
{{Related|MPD/Tips and Tricks}}<br />
{{Related|MPD/Troubleshooting}}<br />
{{Related articles end}}<br />
'''[http://www.musicpd.org/ MPD]''' ('''m'''usic '''p'''layer '''d'''aemon) is an audio player that has a server-client architecture. It plays audio files, organizes playlists and maintains a music database all while using very few resources. In order to interface with it, a separate [[#Clients|client]] is needed.<br />
<br />
== Installation ==<br />
<br />
The latest stable version of {{Pkg|mpd}} is available in the [[official repositories]].<br />
<br />
Should users wish to run an experimental version, the [[AUR]] offers several from which to choose. For example, {{AUR|mpd-git}}.<br />
{{Note|An alternative plug-in based implementation called [http://www.mopidy.com Mopidy] exists. It is available in the AUR as {{AUR|mopidy}} and {{AUR|mopidy-git}}. Be warned that is not a complete MPD [http://docs.mopidy.com/en/latest/ext/mpd/#limitations drop-in relacement].}}<br />
<br />
== Setup ==<br />
<br />
MPD is able to run locally (per user settings), globally (settings apply to all users), and in multiple instances. The way of setting up mpd depends on the way it is intended to be used: a local configuration may prove more useful on a desktop system, for example.<br />
<br />
In order for MPD to be able to play back audio, [[ALSA]] or [[OSS]] (optionally with [[PulseAudio]]) needs to be setup and working.<br />
<br />
MPD is configured in {{ic|mpd.conf}}. The location of this file depends on how you want to run MPD (see the sections below). These are commonly used configuration options:<br />
* {{ic|pid_file}} - The file where mpd stores its process ID<br />
* {{ic|db_file}} - The music database<br />
* {{ic|state_file}} - MPD's current state is noted here<br />
* {{ic|playlist_directory}} - The folder where playlists are saved into<br />
* {{ic|music_directory}} - The folder that MPD scans for music<br />
* {{ic|sticker_file}} - The sticker database<br />
<br />
{{Note|The files must already exist (the path is specified in the configuration file) with proper permissions, otherwise MPD will fail to start.}}<br />
<br />
=== Global configuration ===<br />
<br />
{{Warning|Users of PulseAudio with a global mpd have to implement a [[Music Player Daemon/Tips and Tricks#Local (with separate mpd user)|workaround]] in order to run mpd as its own user!}}<br />
<br />
The default {{ic|/etc/mpd.conf}} keeps the setup in {{ic|/var/lib/mpd}} and uses ''mpd'' as default user. However, {{ic|/var/lib/mpd}} is owned by ''root'' by default, we need to change this so ''mpd'' can write here:<br />
# chown -R mpd /var/lib/mpd<br />
<br />
Edit {{ic|/etc/mpd.conf}} and add a {{ic|music_directory}} line with the path to your music directory:<br />
music_directory /path/to/music<br />
<br />
==== Music directory ====<br />
<br />
MPD needs to have {{ic|+x}} permissions on ''all'' parent directories to the music collection. <br />
<br />
If the music directory is located outside of {{ic|/var/lib/mpd}}, you will most likely need to remount the music directory under a directory that the MPD user (''mpd'' by default) has access to:<br />
# mkdir /var/lib/mpd/music<br />
# echo "/path/to/music/dir /var/lib/mpd/music none bind" >> /etc/fstab<br />
# mount -a<br />
Also see [https://bbs.archlinux.org/viewtopic.php?id=86449 this forum thread].<br />
<br />
An additional solution would be to just create a symbolic link into {{ic|/var/lib/mpd/music}}.<br />
# mkdir /var/lib/mpd/music<br />
# ln -s /path/to/music/dir /var/lib/mpd/music/<br />
<br />
If the music collection is contained under multiple directories, create symbolic links under the main music directory in {{ic|/var/lib/mpd}}. Remember to set permissions accordingly on the directories being linked.<br />
<br />
==== Start MPD ====<br />
<br />
MPD can be controlled with {{ic|mpd.service}} [[systemd#Using units|using systemd]]. The first startup can take some time as MPD will scan your music directory.<br />
<br />
Test everything by starting a client application ({{Pkg|ncmpc}} is a light and easy to use client), and play some music!<br />
<br />
===== Socket activation =====<br />
<br />
If the following {{ic|mpd.socket}} file is enabled while {{ic|mpd.service}} (provided by {{Pkg|mpd}}) is disabled, systemd will not start mpd immediately, but it will listen on the appropriate sockets. When an mpd client attempts to connect on one of those sockets, systemd will start {{ic|mpd.service}} and transparently hand over control of those ports to the mpd process.<br />
<br />
If you prefer to listen on different UNIX sockets or network ports (even multiple sockets of each type), or if you prefer not to listen on network ports at all, you should add/edit/remove the appropriate {{ic|1="ListenStream="}} lines in the {{ic|[Socket]}} section of {{ic|mpd.socket}} '''and''' modify the appropriate lines {{ic|/etc/mpd.conf}} (see {{ic|man 5 mpd.conf}} for details).<br />
<br />
If you use different (even multiple) network or local sockets, or prefer not to use network sockets at all, simply add, change, or remove lines beginning with {{ic|1="ListenStream="}} in the {{ic|[Socket]}} section.<br />
<br />
{{hc|/etc/systemd/system/mpd.socket|<nowiki><br />
[Unit]<br />
Description=Music Player Daemon Sockets<br />
<br />
[Socket]<br />
ListenStream=/var/run/mpd/socket<br />
ListenStream=6600<br />
<br />
[Install]<br />
WantedBy=sockets.target<br />
</nowiki>}}<br />
<br />
==== Configure audio ====<br />
<br />
To change the volume for mpd independent from other programs, uncomment or add this switch in mpd.conf:<br />
{{hc|/etc/mpd.conf|<br />
mixer_type "software"<br />
}}<br />
<br />
Users of [[ALSA]] will want to have the following device definition, which allows software volume control in the MPD client to control the volume separately from other applications.<br />
{{hc|/etc/mpd.conf|2=<br />
audio_output {<br />
type "alsa"<br />
name "My Sound Card"<br />
mixer_type "software" # optional<br />
}<br />
}}<br />
<br />
Users of [[PulseAudio]] will need to make the following modification:<br />
{{hc|/etc/mpd.conf|2=<br />
audio_output {<br />
type "pulse"<br />
name "pulse audio"<br />
}<br />
}}<br />
<br />
PulseAudio supports multiple advanced operations, e.g. transferring the audio to a different machine. For advanced configuration with MPD see [http://mpd.wikia.com/wiki/PulseAudio Music Player Daemon Community Wiki].<br />
<br />
==== Changing user ====<br />
<br />
Changing the group that MPD runs as may result in errors like {{ic|output: Failed to open "My ALSA Device"}}, {{ic|[alsa]: Failed to open ALSA device "default": No such file or directory}} or {{ic|player_thread: problems opening audio device while playing "Song Name.mp3"}}.<br />
<br />
This is because the MPD users need to be part of the ''audio'' group to access sound devices under {{Ic|/dev/snd/}}. To fix it add user make the MPD user part of the ''audio'' group:<br />
# gpasswd -a '''mpd''' audio<br />
<br />
==== Timeline of MPD startup ====<br />
<br />
To depict when MPD drops its superuser privileges and assumes those of the user set in the configuration, the timeline of a normal MPD startup is listed here:<br />
<br />
# Since MPD is started as root by systemd, it first reads the {{ic|/etc/mpd.conf}} file.<br />
# MPD reads the user variable in the {{ic|/etc/mpd.conf}} file, and changes from root to this user.<br />
# MPD then reads the contents of the {{ic|/etc/mpd.conf}} file and configures itself accordingly.<br />
<br />
Notice that MPD changes the running user from root to the one named in the {{ic|/etc/mpd.conf}} file. <br />
This way, uses of {{ic|~}} in the configuration file point correctly to the home user's directory, and not root's directory. <br />
It may be worthwhile to change all uses of {{ic|~}} to {{ic|/home/username}} to avoid any confusion over this aspect of MPD's behavior.<br />
<br />
=== Local configuration (per user) ===<br />
<br />
MPD can be configured per user (rather than the typical method of configuring MPD globally). Running MPD as a normal user has the benefits of:<br />
<br />
* A single directory {{ic|~/.config/mpd/}} (or any other directory under {{ic|$HOME}}) that will contain all the MPD configuration files.<br />
* Easier to avoid unforeseen read/write permission errors.<br />
<br />
Good practice is to create a single directory for the required files and playlists. It can be any directory for which you have read and write access, e.g. {{ic|~/.config/mpd/}} or {{ic|~/.mpd/}}. This section assumes it is {{ic|~/.config/mpd/}}, which corresponds to the default value of {{ic|$XDG_CONFIG_HOME}} (part of [http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html XDG Base Directory Specification]).<br />
<br />
MPD searches for a config file in {{ic|$XDG_CONFIG_HOME/mpd/mpd.conf}} and then {{ic|~/.mpdconf}}. It is also possible to pass other path as command line argument.<br />
<br />
Copy the example configuration file to desired location, for example:<br />
<br />
$ cp /usr/share/doc/mpd/mpdconf.example ~/.config/mpd/mpd.conf<br />
<br />
Edit {{ic|~/.config/mpd/mpd.conf}} and specify the required files:<br />
<br />
{{hc|~/.config/mpd/mpd.conf|<br />
# Required files<br />
db_file "~/.config/mpd/database"<br />
log_file "~/.config/mpd/log"<br />
<br />
# Optional<br />
music_directory "~/music"<br />
playlist_directory "~/.config/mpd/playlists"<br />
pid_file "~/.config/mpd/pid"<br />
state_file "~/.config/mpd/state"<br />
sticker_file "~/.config/mpd/sticker.sql"<br />
}}<br />
<br />
Create all the files and directories as configured above:<br />
<br />
$ mkdir ~/.config/mpd/playlists<br />
$ touch ~/.config/mpd/{database,log,pid,state,sticker.sql}<br />
<br />
When the paths of required files are configured, MPD can be started. To specify custom location of the configuration file:<br />
<br />
$ mpd ''config_file''<br />
<br />
==== Autostart on tty login ====<br />
<br />
To start MPD on login add the following to {{ic|~/.profile}} (or another [[Autostarting#Shells|autostart file]]):<br />
<br />
# MPD daemon start (if no other user instance exists)<br />
[ ! -s ~/.config/mpd/pid ] && mpd<br />
<br />
==== Autostart in X ====<br />
<br />
If you use a [[Desktop environment|desktop environment]], place the following file in {{ic|~/.config/autostart/}}:<br />
{{hc|~/.config/autostart/mpd.desktop|<nowiki><br />
[Desktop Entry]<br />
Encoding=UTF-8<br />
Type=Application<br />
Name=Music Player Daemon<br />
Comment=Server for playing audio files<br />
Exec=mpd<br />
StartupNotify=false<br />
Terminal=false<br />
Hidden=false<br />
X-GNOME-Autostart-enabled=false<br />
</nowiki>}}<br />
<br />
If you do not use a DE, place the line from [[#Autostart on tty login]] in your [[Autostarting#Graphical|autostart file]].<br />
<br />
==== Autostart with systemd ====<br />
<br />
{{Note|It is assumed that you already have systemd user-session manager running. See the [[systemd/User]] page for details.}}<br />
<br />
The package {{Pkg|mpd}} provides user service file in {{ic|/usr/lib/systemd/user/mpd.service}}. The configuration file is expected to exist either in {{ic|~/.mpdconf}} or {{ic|~/.config/mpd/mpd.conf}}, see [[systemd#Editing provided unit files]] if you would like to use different path. The process is not started as root, so you should not use the {{ic|user}} and {{ic|group}} variables in the MPD configuration file, the process already has user permissions and therefore it is not necessary to change them further.<br />
<br />
All you have to do is enable and start the {{ic|mpd}} [[systemd/User#User Services|user service]].<br />
<br />
{{Note|<br />
* {{Pkg|mpd}} provides also system service file in {{ic|/usr/lib/systemd/system/mpd.service}}, but as the process is started as root, it does not read the user configuration file and falls back to {{ic|/etc/mpd.conf}}. [[#Global configuration|Global configuration]] is described in other section.<br />
* Make sure to disable every other method of starting mpd you used before.<br />
}}<br />
<br />
==== Scripted configuration ====<br />
<br />
Rasi has written a script that will create the proper directory structure, configuration files and prompt for the location of the user's Music directory; it can be downloaded [http://dl.53280.de/mpdsetup.sh here].<br />
<br />
=== Multi-mpd setup ===<br />
<br />
'''Useful if running an icecast server.'''<br />
<br />
For a second MPD (e.g., with icecast output to share music over the network) using the same music and playlist as the one above, simply copy the above configuration file and make a new file (e.g., {{ic|/home/username/.mpd/config-icecast}}), and only change the log_file, error_file, pid_file, and state_file parameters (e.g., {{ic|mpd-icecast.log}}, {{ic|mpd-icecast.error}}, and so on); using the same directory paths for the music and playlist directories would ensure that this second mpd would use the same music collection as the first one e.g., creating and editing a playlist under the first daemon would affect the second daemon as well. Users do not have to create the same playlists all over again for the second daemon. Call this second daemon the same way from {{ic|~/.xinitrc}} above. (Just be sure to have a different port number, so as to not conflict with the first mpd daemon).<br />
<br />
== Clients ==<br />
<br />
A separate client is needed to control mpd. See a long list of clients at the [http://mpd.wikia.com/wiki/Clients mpd wiki]. Popular options are:<br />
<br />
=== Console ===<br />
<br />
*{{App|mpc|Simple KISS client. All basic functionality available|http://mpd.wikia.com/wiki/Client:Mpc|{{Pkg|mpc}}}}<br />
*{{App|ncmpc|Ncurses client for mpd|http://mpd.wikia.com/wiki/Client:Ncmpc|{{Pkg|ncmpc}}}}<br />
*{{App|[[ncmpcpp]]|Almost exact clone of ncmpc with some new features written in C++ (tag editor, search engine)|http://unkart.ovh.org/ncmpcpp/|{{Pkg|ncmpcpp}}}}<br />
*{{App|pms|Highly configurable and accessible ncurses client|http://pms.sourceforge.net/|{{AUR|pmus}}}}<br />
*{{App|vimpc|Ncurses based MPD client with vi-like key bindings|http://sourceforge.net/projects/vimpc/|{{AUR|vimpc}}}}<br />
<br />
=== Graphical ===<br />
<br />
*{{App|Ario|Very feature-rich GTK2 GUI client for mpd, inspired by Rhythmbox|http://ario-player.sourceforge.net/|{{Pkg|ario}}}}<br />
*{{App|QmpdClient|GUI client written with Qt 4.x|http://bitcheese.net/wiki/QMPDClient|{{Pkg|qmpdclient}}}}<br />
*{{App|Sonata|Elegant Python GTK+ client|http://sonata.berlios.de/|{{Pkg|sonata}}}}<br />
*{{App|gmpc|GTK2 frontend for Music Player Daemon. It is designed to be lightweight and easy to use, while providing full access to all of MPD's features. Users are presented with several different methods to browse through their music. It can be extended by plugins, of which many are available.|http://gmpc.wikia.com/wiki/Gnome_Music_Player_Client|{{Pkg|gmpc}}}}<br />
*{{App|Dmpc|Dmenu-based MPC client with a playlist manager and state-saving on playlist changes|http://wintervenom.mine.nu/|{{AUR|dmpc}}}}<br />
*{{App|Cantata|High-feature, Qt4/KDE4 client for MPD with very configurable interface|https://code.google.com/p/cantata/|{{AUR|cantata-qt}}}}<br />
<br />
=== Web ===<br />
<br />
*{{App|Patchfork|Web client for MPD written in PHP and Ajax|http://mpd.wikia.com/wiki/Client:Pitchfork|{{AUR|patchfork-git}}}}.<br />
<br />
== See also ==<br />
<br />
* [http://forum.musicpd.org/ MPD Forum]<br />
* [http://www.musicpd.org/doc/user/ MPD User Manual]<br />
* [[Wikipedia:Music Player Daemon|Wikipedia article]]</div>Bwidhttps://wiki.archlinux.org/index.php?title=Talk:LVM&diff=282949Talk:LVM2013-11-15T13:27:00Z<p>Bwid: del walkthrough on how to do lvm setup in the old menu based installer (/arch/setup)</p>
<hr />
<div><br />
== Templates ==<br />
<br />
I notice this article has several areas marked with '''Attention:''', '''Information:''', '''Hint:''', etc. Before I go on an editing frenzy, are templates (like <nowiki>{{Warning|...}}</nowiki>) the preferred format? If so, I will quite happily go through and change all of them. I'm new to this wiki, so I thought I'd ask before stirring up dust. :-) [[User:Infiniteh|Infiniteh]] 16:56, 27 August 2010 (EDT)<br />
<br />
:I went ahead and added templates to the first few sections and did some minor restructuring. However, I may revert my changes (or rethink them). All these colored text boxes seem to make the page less readable... Any thoughts? [[User:Infiniteh|Infiniteh]] 21:11, 28 August 2010 (EDT)<br />
<br />
::The page looks nicer with new templates :). I think a few colored text boxes could be removed. For example: "Note: You may need to load the device-mapper kernel module (modprobe dm-mod) for the above commands to succeed" could be easily removed, because that info is stated at the begining of the article. I think that warnings should stay though. [[User:Billy|billy]] 04:46, 5 September 2010 (EDT)<br />
<br />
== LVM-recovery section ==<br />
<br />
Would a section on LVM un-borkage be useful and/or within the scope of this article? [[User:Buhman|Buhman]] 13:45, 29 April 2012 (UTC)<br />
:All constructive contributions are welcome. However if you're going to simply rewrite some existing and well maintained documentation, it'd be better to just write an introduction and link to it; if instead you want to write an Arch-oriented section or something more original in general, then go for it :) -- [[User:Kynikos|Kynikos]] 09:53, 30 April 2012 (UTC)<br />
<br />
<br />
== PROS and CONS (citing needed) ==<br />
<br />
Can anybody please come up with and elaborate on some of the cons as to what the drawbacks in performance and wear and tear would be when having multple LVM partitions spread and intertwined across several hard drives? (vs. keeping partitions spread evenly and limited to one drive only)<br />
<br />
Cons should be clearly listed on the main 'page' ("cons", or "disadvantages", maybe near "advantages")<br />
<br />
In fact, upon reading the 'advantages' section is what had me anticipating there would be something on disadvantages. I'm concerned about hard performance testing results. Has anyone seen any good data on this?<br />
<br />
<br />
: I did some work on this, consolidating the advantages which where listed in 2 different sections before. I picked some disadvantages which come to my mind, also some points from the german language version of the article.<br />
: No idea if there is any performance impact of lvm.<br />
: Also i removed 2 points in advantages:<br />
: * Name your VG and LV as you like -> Don't see that as adv. when compared to normal partitions. That you can name them is nice, it would be pretty mean if you could not.<br />
: * No need for an extended partition -> Never saw the extended/logical-partition thing as anything more than a minor wart from a user perspective.<br />
[[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 12:25, 11 March 2013 (UTC)</div>Bwid