https://wiki.archlinux.org/api.php?action=feedcontributions&user=Moviuro&feedformat=atomArchWiki - User contributions [en]2024-03-28T21:48:25ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&diff=793973Talk:Installation guide2023-12-06T10:11:34Z<p>Moviuro: /* Mention that partitionning is more-or-less permanent */ Reply</p>
<hr />
<div>== Read this first before adding new suggestions ==<br />
<br />
* systemd tools such as ''hostnamectl'', ''timedatectl'' and ''localectl'' [https://github.com/systemd/systemd/issues/798#issuecomment-126568596 do not work] in the installation chroot environment, so please do not propose to use them in the guide unless you can prove that they have been made to work also in that case. See [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=388727#General_problems], [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=404695#Replace_commands_with_their_systemd_equivalents], [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=418662#Utilizing_systemd_tools] and [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=434985#change_configuration_system_from_old_way_to_new_way.28using_systemd_commands.29] for some past discussions about this issue.<br />
* Due to the wide variety of available boot loaders, the installation guide refers to [[Arch boot process#Boot loader]] instead of making a specific recommendation for the installed system. See [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=687325#Bootloader], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=690612#Make_the_Boot_Loader_Section_slightly_more_detailed_to_provide_a_high_level_overview_for_new_users], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=678949#Expand_Boot_loader_section], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=660151#Expand_Boot_loader_section_to_include_example_commands], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=581427#Boot_loader_installation] for some past discussions on this topic.<br />
* While [[:Category:Installation process]] lists additional installation methods (e.g. [[archinstall]] or [[systemd-firstboot]]), the installation guide does not reference them due to their specific nature. [[Install Arch Linux with accessibility options]] is an exception. See [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=698307#Point_out_archinstall] for past discussion on this topic.<br />
-- [[ArchWiki:Administrators|The ArchWiki Administrators]] 22:17, 2 September 2016 (UTC)<br />
__TOC__<br />
<br />
== Link to the German version ==<br />
<br />
Instead of [[de:Arch Install Scripts]] you could choose [[de:Anleitung für Einsteiger]] it means "Beginner's Guid" and is a very <br />
detailed artikel for very new arch users and the future experts.<br />
<br />
:Thank you, [https://wiki.archlinux.org/index.php?title=Installation_guide&type=revision&diff=509961&oldid=508505 done]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:31, 6 February 2018 (UTC)<br />
<br />
::This was already proposed last year and rejected: [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=466950#Suggesting_different_page_for_German_translation]. I don't see what has changed since then. If someone adds me as admin to the german wiki or changes the protection settings, I can update [[de:Arch Install Scripts]] as required. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:13, 6 February 2018 (UTC)<br />
<br />
:::I see, I didn't remember that discussion so I've reverted the change, hopefully you'll make it to update the translation, let's leave this open until the problem is solved, otherwise this kind of suggestion will keep appearing recurrently. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:53, 7 February 2018 (UTC)<br />
<br />
::::Apparently since last year the translation has been halved in size, but its scope is still much larger than the [[Install guide]] (or even the old [[Beginners' guide]]). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 9 May 2021 (UTC)<br />
<br />
== First mention of /mnt in example partition layout ==<br />
<br />
{{ic|/mnt}} is mentioned at mount point in [[Installation_guide#Partition_the_disks]], while {{ic|/mnt}} is made explicit two sections later in [[Installation_guide#Mount_the_file_systems]]. As I recall it, this was changed because some users blindly copy pasted commands and mounted /boot on the live system, instead of /mnt/boot. Some options:<br />
<br />
* Introduce another column describing the mount point on the installed system. <br />
* Actually explain /mnt early.<br />
* Revert the "mount point" to not include /mnt.<br />
<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:03, 7 September 2019 (UTC)<br />
<br />
:I don't understand what's the actual problem here... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:36, 8 September 2019 (UTC)<br />
<br />
::From what I read on [[ArchWiki:IRC|#archlinux-wiki]], this comes from https://www.reddit.com/r/archlinux/comments/d0v0j3/is_it_just_me_or_is_the_prospect_of_installing/ where the user was confused by the lack of root mountpoint (i.e. {{ic|/mnt}} vs {{ic|/}}). A question could be raised, if we should concern ourselves with users who have strong opinions about the wiki content yet can't be bothered to propose improvements in the talk pages...<br />
::About Alad's proposed options: I disagree with the first option, I think it will just complicate things even further. I support the third option and maybe adjusting the column header like in [[Special:Diff/581800]].<br />
::I'd actually would like to go even further and change the commands run from outside chroot to be visually distinct, e.g.: {{bc|1=<span style="color: #ff0000;">root@archiso #</span> mount /dev/sd''X1'' /mnt}}<br />
::I think it would better solve the underlying issue. <br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:26, 8 September 2019 (UTC)<br />
<br />
:::I'm not overly fond of the longer column name. For the last proposed option, I may agree if this is formalized in [[Help:Style]], so that it is not specfic to the [[Installation guide]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:20, 10 September 2019 (UTC)<br />
<br />
::::Adding it [[Help:Style]] was my intention, since other articles, too, will need to use that style for some commands. I'm thinking of creating a template for it: [[Special:Permalink/581945]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:19, 11 September 2019 (UTC)<br />
<br />
:::::Sounds good to me, I'd just prefer the regular (non-bold) font for the prompt as above. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:54, 13 September 2019 (UTC)<br />
<br />
::::::[[Special:Permalink/582327]]. Are there any other opinions about creating such a template? Or should I take this discussion to [[Help talk:Template]] per [[Help:Template#Creation]]? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 18:31, 14 September 2019 (UTC)<br />
<br />
:::::::# How are you going to call the template? This template would probably add to the [[Help:Template#Code formatting templates]] series, should it be named in a consistent fashion?<br />
:::::::# Should this template support custom prompts, and if so, should it be called "pc" (from "(custom) prompted" code)?<br />
:::::::# I don't like the red color too much, if bold is not an option maybe we can go green|purple|blue, something that recalls less a warning of some kind? Or can we just leave it with the default font color? Or a slightly fainter black?<br />
:::::::# I haven't looked well into it, but maybe we can instead add an optional argument to [[Template:bc]] and [[Template:hc]] that prefixes a custom (colored) prompt? I wouldn't see a problem with repeating "root@archiso #" in every instance, or we may derive the new template from those two at that point.<br />
:::::::# The template should probably be derived from [[Template:bc]] in any case, for simpler code, see [[User:Kynikos/Template:Sandbox2]].<br />
:::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:36, 16 September 2019 (UTC)<br />
<br />
::::::::# Initially I was going to call it [[Template:Archiso]] since it would be [[Archiso]]-specific, but I'm starting to think that creating a more general-purpose template would be better. It could then be used in [[PostgreSQL]] and the {{ic|[postgres]$}} convention would get formalized in [[Help:Style]]. Now the issue is the {{ic|[user@peer-a]#}} in [[Template:hc]] used in [[WireGuard]]. I'd rather not create two new templates, but I'm having trouble getting [[Template:Sandbox]] to work :(<br />
::::::::# I like your "[[Template:pc]]" suggestion.<br />
::::::::# Be glad I didn't post my first draft that was ''slightly more'' colorful. From your offered colors, I'd choose purple.<br />
::::::::# I'd rather not mess with the established templates just for this change, so I'd prefer creating a new template.<br />
::::::::# I didn't even think about using [[Template:bc]]. Is it a good idea to do that? The new template might need to be updated if [[Template:bc]] is ever changed in an incompatible way.<br />
:::::::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:33, 17 September 2019 (UTC)<br />
<br />
:::::::::Yeah, after viewing your attempts and looking into it myself, I think modifying bc/hc is out of discussion, it would add too much code/style for so little use.<br />
:::::::::Thinking about this again one day after, I feel I'm realizing that my concerns in general may descend from the fact that we're going to create a template to represent (block) code, even though we already have 2 which basically do the same thing, including allowing to include a prompt; the only addition of this "Archiso" or "pc" template would be the formatting around the prompt, so why not keep it simple (I know, "simplicity" is often subjective and controversial) and instead either make a [[Template:Archiso]] to be used like {{ic|<nowiki>{{bc|{{Archiso}} mount /dev/sdX1 /mnt}}</nowiki>}} or [[Template:ps]] (or [[Template:PS]]) to be used like {{ic|<nowiki>{{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}</nowiki>}}? They also work with [[Template:hc]] and space-prefixed code blocks!<br />
:::::::::Putting the choice of color aside, if the above idea of a standalone prompt template isn't welcome, I think my second choice would be to make two [[Template:pbc]] and [[Template:phc]] that work like {{ic|<nowiki>{{pbc|$|ls}}</nowiki>}} and {{ic|<nowiki>{{phc|$|ls|...}}</nowiki>}}, with the style rule to use them only in case of complex prompts. I'd still derive them from bc/hc to inherit any changes that we'd decide to make to them, and avoid repeating that ugly &lt;pre> hack even more.<br />
:::::::::Otherwise I give up and accept the [[Template:Archiso]] that works like {{ic|<nowiki>{{Archiso|mount /dev/sdX1 /mnt}}</nowiki>}}, in the hope that one day we won't need an analogous "hc" version.<br />
:::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:24, 17 September 2019 (UTC)<br />
<br />
::::::::::I can't say I really like the idea of {{ic|<nowiki>{{bc|{{Archiso}} mount /dev/sdX1 /mnt}}</nowiki>}} or {{ic|<nowiki>{{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}</nowiki>}}. I'd prefer creating [[Template:pbc]] and [[Template:phc]].<br />
::::::::::I still don't get what's wrong with [[Template:Sandbox]]. It should just work:<br />
<br />
<pre<noinclude></noinclude> {{#if: code|style="margin-bottom: 0; border-bottom:none; padding-bottom:0.8em;"}}>prompt # command</pre<noinclude></noinclude>><noinclude><!-- The &lt;noinclude>&lt;/noinclude> hack is needed to allow wiki markup inside the pre tags; reference: http://www.gossamer-threads.com/lists/wiki/mediawiki/118688#118688 --><br />
{{#if: code|<pre<noinclude></noinclude> style="margin-top: 0; border-top-style:dashed; padding-top: 0.8em;">code</pre<noinclude></noinclude>>}}<br />
<br />
:::::::::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 04:43, 18 September 2019 (UTC)<br />
<br />
:::::::::::FWIW (and a bit of fun) I've fixed [[Template:Sandbox]], although I'm not sure if we really need that level of automation ^^ I stick to my position above, is there a third (or more) opinion? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:48, 18 September 2019 (UTC)<br />
<br />
:::::::::I think you like the [https://wiki.archlinux.org/index.php?title=User_talk:Nl6720&diff=447834&oldid=447833 #800080] shade of purple, right? ;-) [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:39, 21 September 2019 (UTC)<br />
<br />
::::::::::Yes, I do like that one :D but I think it would be too bright for this template. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:52, 21 September 2019 (UTC)<br />
<br />
:::::::::::Any news on this one? If not, I haven't seen this kind of issue or confusion occur since. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:37, 31 October 2021 (UTC)<br />
<br />
::::::::::::I don't think I want to create such a template anymore, since it would require updating other installation related pages. To go back to your originally proposed options, I'm for explaining {{ic|/mnt}} early. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:42, 4 November 2021 (UTC)<br />
<br />
== Buggy graphics driver ==<br />
<br />
Can there be a hint that nomodeset parameter could be used if the graphics driver is buggy (I've heard nouveau may be buggy sometimes)<br />
[[User:M.Srikanth|M.Srikanth]] ([[User talk:M.Srikanth|talk]]) 04:47, 12 May 2020 (UTC)<br />
<br />
:I would expect this to be mentioned in [[General_troubleshooting]]... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:43, 31 October 2021 (UTC)<br />
<br />
== GitLab blobs in Lynx ==<br />
<br />
Links to files (blobs) on gitlab.archlinux.org are not readable in Lynx (or any other console web browser); see https://gitlab.com/gitlab-org/gitlab/-/issues/26567.<br />
<br />
Should the Installation guide link to raw files instead?<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:29, 4 August 2020 (UTC)<br />
<br />
:Maybe you could ask svenstaro to add it to https://gitlab.com/gitlab-org/gitlab/-/issues/232073... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:36, 4 August 2020 (UTC)<br />
<br />
::It has been filed under [https://gitlab.com/gitlab-org/gitlab/-/issues/232073#nice-to-have nice to have]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:19, 4 August 2020 (UTC)<br />
<br />
:::Instead of using raw links we should perhaps consider if we need links to gitlab at all. The guide has:<br />
:::* [https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/blob/master/docs/README.bootparams README.bootparams]<br />
:::* <s>[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-ethernet.network Ethernet]</s><br />
:::* <s>[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wlan.network WLAN]</s><br />
:::* <s>[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wwan.network WWAN]</s><br />
:::* <s>[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/xdg/reflector/reflector.conf reflector.conf]</s><br />
:::* <s>[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64 packages.x86_64]</s><br />
:::Notice how all but one of these share the common path [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng archiso/-/blob/master/configs/releng]. Unless this level of specificity is really required, we could link to this path "for an overview of configuration files shipped with archiso" instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:35, 31 October 2021 (UTC)<br />
<br />
::::I'd prefer simply removing some of the links.<br />
::::* [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-ethernet.network Ethernet], [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wlan.network WLAN] and [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wwan.network WWAN] don't provide much value here, so they can be moved to [[systemd-networkd#Configuration examples]].<br />
::::* [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/xdg/reflector/reflector.conf reflector.conf] is there just for citation purposes. The [[reflector]] article already explains how the software works.<br />
:::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:30, 4 November 2021 (UTC)<br />
<br />
::::: Alright, I've removed those links. ([[Special:Diff/700696]], [[Special:Diff/700693]]) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:39, 4 November 2021 (UTC)<br />
<br />
::::: Now that mirrors provide a symlink to the latest ISO version, it's possible to link to {{ic|pkglist.x86_64.txt}}. [[Special:Diff/730318|I replaced packages.x86_64 with it]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:31, 21 May 2022 (UTC)<br />
<br />
:Is Lynx (un)readability such a big problem in this case? People using Lynx from the archiso can open up the relevant file in the live system itself... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:05, 31 October 2021 (UTC)<br />
<br />
== Post-installation ==<br />
<br />
I skipped steps in the guide so I faced a weird crash in gnome without any explanations. I suggest a note.<br />
<br />
{{Note|Many of them assume that you have your timezone or locales set up. Make sure you have followed all the steps.}}<br />
<br />
[[User:Escope|Escope]] ([[User talk:Escope|talk]]) 10:11, 2 April 2021 (UTC)<br />
<br />
:The reader is supposed to follow all the steps. If we apply that to other pages, the pages need a boatload of notes to make sure the reader did not skip any steps. A common functional system has properly configured locales and timezones.<br />
:Since this is GNOME-specific however I would at most add a section into [[GNOME/Troubleshooting]] or even [[General troubleshooting]], but I still think this is out of scope to be honest. Many applications may not work properly when the timezones or locales are not correctly configured.<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 15:30, 2 April 2021 (UTC)<br />
<br />
::The reader is not supposed to follow all the steps in case one doesn't worthy of attention. In my humble opinion, that's why it has huge advantage over the "Next-Next-Finish" approach. Unconfigured locales or timezones are obvious to many people, but my inexperience made me spend some time to sorting out. The other pages are highly deep and clear about the steps and why they are needed, my eyes enjoy such notes, pages are boatloaded already and I like it a lot =D. Thank you for your attention to this little change.<br />
<br />
::-- [[User:Escope|Escope]] ([[User talk:Escope|talk]]) 00:23, 3 April 2021 (UTC)<br />
<br />
:::If you're inexperienced, what makes you think you can judge if a step is necessary or not? You thought you knew better than the people that wrote the guide and found out that you didn't. Not something that needs changed here IMO.<br />
:::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 01:57, 3 April 2021 (UTC)<br />
<br />
:::The ArchWiki should also be about the why-aspect. I am in favor of adding e.g a note about why they are needed and why some applications may crash or behave strangely without properly configured timezones/locales. If you know e.g a nice blog post about this topic, why not add something like this?<br />
:::{{Note|Some applications may behave in strange ways or even crash when the timezones and/or locales are not properly configured. See [https://xkcd.com/1084/ this informative blog post] to know why that is.}}<br />
:::The note needs obviously some rewording, but something like this would fit in well in my opinion.<br />
:::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:02, 3 April 2021 (UTC)<br />
<br />
::::Adding a '''brief''' "why" would be ok, but using [[Template:Note]] would be too much. I've also always wanted to emphasize the "and" in [[Installation guide#Localization]], since it's easy to miss (even some of the translated installation guides do not mention {{ic|en_US.UTF-8 UTF-8}}). --- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:48, 3 April 2021 (UTC)<br />
<br />
:::::People who want to know the "why" can already consult the relevant articles. That said, consistency is lacking: some sections explain in detail why a step should be performed (such as [[Installation_guide#Verify_signature]]), whereas [[Installation_guide#Configure_the_system]] is mostly a checklist of steps with brief instructions how. The solution isn't obvious: adding notes all over would likely more distract than clarify. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:41, 14 April 2021 (UTC)<br />
<br />
::::::I'm definitely apposed to adding notes, but I don't see why we couldn't add brief "why"s without them. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:55, 15 April 2021 (UTC)<br />
<br />
== Note on Network Setup ==<br />
<br />
One of the most common installation issues that comes up on Reddit, Forums, and other discussion areas is not having done any sort of network setup. While the Installation Guide explicitly call out Network Setup as a required step, I suspect people are mistakenly believing the setup steps they did already to establish a connection on the installer will carry over to their installed system. <br />
<br />
I propose adding a note such as (example content):<br />
<br />
{{Note| Configuring your network connection above only established your network for the installer. This section will configure the network for your installed Arch system. Failure to do so may leave you without network access after completing installation.}} [[User:Nalthien|Nalthien]] ([[User talk:Nalthien|talk]]) 17:40, 15 May 2022 (UTC)<br />
<br />
:Such a thing [[Help:Style#Notes, Warnings, Tips|does not warrant a warning]] since there's nothing dangerous about being offline. It may even be the safest state the system will ever be. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:24, 18 May 2022 (UTC)<br />
<br />
:: I can agree that it doesn't warrant a Warning given the style guide; however, I do think a Note would be appropriate to "highlight information easily overlooked." It's clearly overlooked quite often. [[User:Nalthien|Nalthien]] ([[User talk:Nalthien|talk]]) 17:36, 20 May 2022 (UTC)<br />
<br />
:[[Installation guide#Connect to the internet]] already explains (or tries to, at least) that the live environment's network setup has nothing to do with the installed system. Perhaps the list items in [[Installation guide#Install essential packages]] could be made a little more verbose to explain '''why''' someone may want to install those things. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:24, 18 May 2022 (UTC)<br />
<br />
I propose adding something like the following:<br />
<br />
''To configure the freshly installed system's network for out-of-the-box ethernet DHCP functionality as on the installation image, create a simple /etc/systemd/network/20-wired.network file for your adapter Name, eg:''<br />
<br />
[Match]<br />
<br />
Name=enp1s0<br />
<br />
[Network]<br />
<br />
DHCP=yes<br />
<br />
''Also, enable both systemd-networkd.service and systemd-resolved.service''<br />
<br />
1. It will only take up a few lines; it is succinct, effective and informative. <br />
2. Further, the functionality on reboot will mimic functionality in the installation image.<br />
3. It uses simple built-in services without installing anything extra. <br />
4. It will also cut down on forum noise immensely.<br />
[[User:Misfit138|Misfit138]] ([[User talk:Misfit138|talk]] 11:11 21 March 2023 (UTC-5)<br />
<br />
: It's also incomplete, as systemd-resolved takes some setup. And it would cause more problems on the forums when people then enable NM or whatever and have both. There's a reason the network configuration page is linked. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 15:14, 21 March 2023 (UTC)<br />
<br />
:: systemd-resolved setup is optional according to the network configuration page, and I can confirm this to be the case on a bare-metal workstation as well as a VM. Doing the above minimal steps results in full functionality for a simple dhcp setup and mimics the ootb install image function. Further, installing NM as you indicated would result in a chicken or egg problem before reading a wall of text and realizing they have to setup a trivial and perhaps temporary dhcp solution in order to install a more permanent one anyway. The user has the ability to install packages in the chrooted environment, yes, but the expectation of a functional network in a freshly booted system is reasonable. One explanatory sentence or phrase can inform users that only one network config scheme is needed, as well as a brief warning to avoid conflicts (such warnings already exist elsewhere). The net conf. page can and should still be linked, but it is a monstrous page for something so trivial that can be suggested so succinctly. sent from my phone, will clean up formatting. -- [[User:Misfit138|Misfit138]] ([[User talk:Misfit138|talk]]) 11:37 22 March 2023 (UTC-5)<br />
<br />
:::systemd-networkd only supports using systemd-resolved for DNS. A network connection without working DNS is not something most people would want. I think the best we could do is to explicitly link to [[systemd-networkd]] as an example in [[Installation guide#Install essential packages]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:16, 22 March 2023 (UTC)<br />
<br />
::::With just the /etc/systemd/network/20-wired.network file, and no other network tools, and after starting networkd and resolved, I can ping sites and visit urls with links and lynx; ostensibly, something is resolving DNS for me(?) (Confirmed on VM and bare-metal.) However, I must regretfully admit that I am not likely to compel you with the principles I have set forth. Thank you for your time and for considering this. -- [[User:Misfit138|Misfit138]] ([[User talk:Misfit138|talk]]) 13:35 22 March 2023 (UTC-5)<br />
<br />
:::::I missed that you suggested to also enable {{ic|systemd-resolved.service}}. In that case, just as [[systemd-resolved#DNS]] says, DNS will only work for software that do not parse {{ic|/etc/resolv.conf}} themselves. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:44, 22 March 2023 (UTC)<br />
<br />
:Perhaps the "software necessary for networking" bullet point in [[Installation guide#Install essential packages]] could be extended with a tip that suggests using systemd-networkd + systemd-resolved and copying {{ic|/etc/systemd/network/20-ethernet.network}} from the live environment. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:18, 28 April 2023 (UTC)<br />
<br />
::The crosslinked article already has a note, that could be added there instead, similar to [[Special:diff/773727]]. <br />
::While I see the point of this item, the systemd- tools are probably not the most beginner-friendly ones to configure networking anyway (for some use-cases ok, not for the scope of this guide. Other tools like netctl are arguably simpler to use). The skill to configure networking is important and that's not triggered by copying an autogenerated file. What's the general state of [[archinstall]]? Could it be a solution to add a tip for Arch newcomers at the beginning of the guide to it instead?<br />
::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:45, 29 April 2023 (UTC)<br />
<br />
:::My idea was to ''somehow'' replace the note in [[Installation guide#Connect to the internet]] with a tip in [[Installation guide#Install essential packages]]. If there's no good way to do it, then let's keep things as is.<br />
:::archinstall would probably warrant an entirely separate discussion.<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:02, 30 April 2023 (UTC)<br />
<br />
== Missing pacman-key steps ? ==<br />
<br />
I just tried (using archlinux-2022.11.01-x86_64.iso) the standard archlinux installation (pacstrap) following the guide,<br />
and once the packages were downloaded, they failed to install with errors like:<br />
* "signature from <maintainer> is unknown trust"<br />
<br />
I found on the web the following commands to solve the issue: (https://bbs.archlinux32.org/viewtopic.php?id=2900)<br />
* pacman-key --init<br />
* pacman-key --populate archlinux<br />
<br />
After those two commands, the pacstrap installation works fine.<br />
<br />
If those two commands are needed, shouldn't we document them in the Installation guide ?<br />
<br />
(note that the same problem/solution is applicable to archinstall method too)<br />
<br />
{{Unsigned|23:02, 3 November 2022 (UTC)|Nsauzede}}<br />
<br />
:This is already done by pacman-init.service. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 23:38, 3 November 2022 (UTC)<br />
<br />
:I hit the exact same problem with same installation iso. I got the solution from https://wiki.archlinux.org/title/Pacman/Package_signing<br />
:{{Unsigned|2022-12-02T07:53:41|Roblaing}}<br />
<br />
: This is caused by out of date keyring, what really should be added to the installation guide is starting the keyring sync service {{ic|systemctl start archlinux-keyring-wkd-sync}} before the pacstrap step, with a warning to check that it has finished running before continuing. This will allow both older ISOs to work and even current ISOs to work. December ISO is once again broken right now as openssl has too new a key. [[User:C0rn3j|C0rn3j]] ([[User talk:C0rn3j|talk]]) 23:21, 24 December 2022 (UTC)<br />
::archlinux-keyring-wkd-sync doesn't 'sync' the keyring, it refreshes it which is only helpful in a limited set of circumstances. Most of the time, it won't help these errors. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 03:21, 25 December 2022 (UTC)<br />
::: It however helps with the current issue and am sure the previous issues too, as they were fixable with partially installing archlinux-keyring on the ISO before. I am not aware of a better solution, unless reinitializing and populating the keyring as per OP is actually preferred? [[User:C0rn3j|C0rn3j]] ([[User talk:C0rn3j|talk]]) 11:05, 25 December 2022 (UTC)<br />
::::Reinitializing and populating the keyring is a solution for a completely different problem. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 13:32, 25 December 2022 (UTC)<br />
<br />
== Add tip for easily booting iPXE-arch.efi file from almost all hardware ==<br />
<br />
For most scenarios (I assume) it isn't necessary to flash an USB drive or burn a disk.<br />
You can simply put the PXE EFI binary on a drive and boot it from "BIOS" directly (works e.g. on Dell hardware). If your BIOS does not support loading arbitrary files directly, you can use the UEFI shell to do so if available. Otherwise you can simply put the image under {{ic|/EFI/BOOT/}} and name it bootx64.efi and select this drive from the boot menu. The drive might even be the boot partition, if you are going to do a reinstall. (Tested on Lenovo and Fujitsu notebooks) [[User:Flacer|Flacer]] ([[User talk:Flacer|talk]]) 14:06, 26 January 2023 (UTC)<br />
<br />
:[[Installation guide#Acquire an installation image]] already mentions the netboot image. And yes, it should work just fine on any system with an Ethernet connection. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:13, 26 January 2023 (UTC)<br />
<br />
:: That is true, but in my opinion it would be beneficial to emphasize this because esp. new users think of setting up a server etc. (me too, although I'm not quite a new user; discovered this by accident).<br />
<br />
::So it would be better to put it under [[Netboot]]? Anyway it would be helpful to place a link to that page, most appropriately under 1.3. -- [[User:Flacer|Flacer]] ([[User talk:Flacer|talk]]) 15:42, 26 January 2023 (UTC)<br />
<br />
:::I could be wiki-linked from 1.1 and ''somehow'' mentioned in 1.3. Just need to find the right words for it. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:55, 1 February 2023 (UTC)<br />
<br />
::::I think an additional link in 1.1 is too early. Currently, the downloads landing page links a dedicated netboot page, which at the end leads to the wiki article. Linking it earlier may mislead to users skipping the gpg steps in 1.2. and the landing page.<br />
::::In 1.3 we could replace "or a network with [[PXE]]:" with "or an appropriate [[PXE]]" for starters. And complement that by adding to the last intro sentence in [[PXE]] "This works well when you already have a server set up, but may (for installation purposes) also load the image directly from an official Arch mirror."<br />
::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:52, 3 February 2023 (UTC)<br />
<br />
:::::I'm not too sure about "or an appropriate [[PXE]]". I assume most people would just place the netboot EFI binary in a USB flash drive and boot it directly. The fact that the images are iXPE builds is not that relevant. Perhaps 1.3 needs to explicitly differentiate the deployment methods of the ISO and netboot images since the links in the section are ISO specific. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:02, 4 February 2023 (UTC)<br />
<br />
::::::True, like two bullet points for ISO and iPXE in 1.3. I proposed "appropriate PXE", because (as Flacer mentions) current "network [[PXE]]" does indeed sound like you need to set up a server when you visit the article. How about switching [[PXE]] links to [[netboot]]?<br />
::::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:23, 5 February 2023 (UTC)<br />
<br />
:::::::Well, you can still PXE-boot the ISO contents as the [[PXE]] article describes, so I don't think it's correct to remove the links.<br />
:::::::I would probably be best if [[Netboot]] had instructions on how to create a bootable medium from the image. At least for UEFI, since that's dead simple. IMHO 1.3. could then be turned into two sentences, one for the ISO deployment, one for netboot.<br />
::::::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:52, 6 February 2023 (UTC)<br />
<br />
::::::::Sure, it can; see the sentence I proposed above for [[PXE]]. I agree it is more important to edit both articles first. The simple method proposed by Flacer can be turned into a tip in the [[Netboot]] section you suggest. Afterwards we can see what changes are still useful in this main guide. Perhaps this item should be moved to [[Talk:Netboot]] for implementation first. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:44, 16 February 2023 (UTC)<br />
<br />
:::::::::There's [[Netboot#Boot from a USB flash drive]] that can be linked now. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:10, 26 March 2023 (UTC)<br />
<br />
:::::::::I drafted something below. [[Installation guide#Boot the live environment]] will need adjustment too, so suggestions welcome. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:59, 24 June 2023 (UTC)<br />
<br />
::::::::::I added an draft for [[Installation guide#Boot the live environment]] below. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:05, 16 November 2023 (UTC)<br />
<br />
=== Prepare an installation medium (draft) ===<br />
<br />
The ISO can be supplied to the target machine via a [[USB flash installation medium|USB flash drive]], an [[Optical disc drive#Burning|optical disc]] or a network with [[PXE]]: follow the appropriate article to prepare yourself an installation medium from the ISO file.<br />
<br />
For the netboot image, follow [[Netboot#Boot from a USB flash drive]] to prepare a USB flash drive for UEFI booting.<br />
<br />
=== Boot the live environment (draft) ===<br />
<br />
{{Note|Arch Linux installation images do not support Secure Boot. You will need to [[Unified Extensible Firmware Interface/Secure Boot#Disabling Secure Boot|disable Secure Boot]] to boot the installation medium. If desired, [[Secure Boot]] can be set up after completing the installation.}}<br />
<br />
# Point the current boot device to the one which has the Arch Linux installation medium. Typically it is 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 />
# When the installation medium's boot loader menu appears,<br />
#* if you used the ISO, select ''Arch Linux install medium'' and press {{ic|Enter}} to enter the installation environment. <br />
#* if you used the Netboot image, choose a geographically close mirror from ''Mirror'' menu, then select ''Boot Arch Linux'' and press {{ic|Enter}}. {{Tip|<br />
#** The ISO uses [[GRUB]] for UEFI and [[syslinux]] for BIOS booting. Use respectively {{ic|e}} or {{ic|Tab}} to enter the [[Kernel parameters#Configuration|boot parameters]]. The Netboot image uses iPXE and the boot parameters can be specified in the ''Boot options'' menu. See [https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/blob/master/docs/README.bootparams README.bootparams] for a list.<br />
#** A common example of manually defined boot parameter would be the font size. For better readability on HiDPI screens—when they are not already recognized as such—using {{ic|1=fbcon=font:TER16x32}} can help. See [[HiDPI#Linux console (tty)]] for a detailed explanation.<br />
#}}<br />
# You will be logged in on the first [[Wikipedia:Virtual console|virtual console]] as the root user, and presented with a [[Zsh]] shell prompt.<br />
<br />
To switch to a different console—for example, to view this guide with [https://lynx.invisible-island.net/lynx_help/Lynx_users_guide.html Lynx] alongside the installation—use the {{ic|Alt+''arrow''}} [[Keyboard shortcuts|shortcut]]. To [[textedit|edit]] configuration files, {{man|1|mcedit}}, [[nano#Usage|nano]] and [[vim#Usage|vim]] are available. See [https://geo.mirror.pkgbuild.com/iso/latest/arch/pkglist.x86_64.txt pkglist.x86_64.txt] for a list of the packages included in the installation medium.<br />
<br />
== Mention zram ==<br />
<br />
In [[Installation guide#Partition the disks]], The note mentions:<br />
<br />
:* [[Swap]] space can be set on a [[swap file]] for file systems supporting it.<br />
Should it be updated to add reference to [[zram]] as well ? Something like :<br />
:* As an alternative to a swap partition, [[Swap]] space can be set on a [[swap file]] for file systems supporting it, or in a [[Zram|compressed block device in ram]].<br />
<br />
-- [[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 23:04, 30 January 2023 (UTC)<br />
<br />
:I do not think zram is essential enough (compared to the defaults) for it to be mentioned in the [[Installation guide]], or even in [[General recommendations]]. The [[Improving performance|snake oil article]] references it and IMHO that's enough. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:22, 31 January 2023 (UTC)<br />
<br />
::(Re-opened, hope that's ok)<br />
::Certainly not essential, but it's one possible reason not to plan for a swap partition during the partitioning step. Distros like Fedora provide that [https://fedoraproject.org/wiki/Changes/SwapOnZRAM by default], it's a reasonable way to set up a system, I don't see any harm in mentioning it. People often read the installation guide many times before actually installing Arch, it's a perfect way to learn about possibilities, whereas [[Improving performance]] is probably most often read after installation on a running system. Swap files are already mentioned, so it doesn't require any extra note or clutter, just modifying a sentence, which is nice.<br />
::-- [[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 16:16, 31 January 2023 (UTC)<br />
<br />
:::If it were to be added to the installation guide, I want it to contain the phrase "swap on zram" instead of obfuscating it with "compressed block device in ram" or similar.<br />
:::I don't think we can link to [[Zram#Usage as swap]] unless it has a suggested size for the swap space.<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:13, 22 June 2023 (UTC)<br />
<br />
:: I was about to say, we can just link to the suggested size from the [[swap]] article but... there is no suggested size there either :)<br />
:: -- [[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 15:09, 22 June 2023 (UTC)<br />
<br />
:::There's [[Partitioning#Swap]], which IMO should be linked from [[Swap#Swap file]], but it doesn't actually say anything specific. Instead the recommended size is only listed in the [[Partitioning#Example layouts]] table.<br />
:::Still, does the general swap size recommendation apply to swap on zram? Is wasting 512 MiB of RAM enough?<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:24, 22 June 2023 (UTC)<br />
<br />
:: No you're right, the general swap size recommendation does not really apply to zram. A percentage of available RAM makes more sense. {{ic|zram-generator}} has a default of {{ic|1=zram-size = min(ram / 2, 4096)}}, Fedora uses [https://fedoraproject.org/wiki/Releases/34/ChangeSet#Scale_ZRAM_to_Full_Memory_Size 100%] of RAM. I've been using 100% without problems for quite a while. I would suggest 100% for regular desktop/laptop use, and 50% if having to deal with specific non compressible workloads (not sure what this would be though, I've had no problem with encoding of large video files, or such).<br />
:: -- [[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 16:50, 22 June 2023 (UTC)<br />
<br />
:::[[Fedora:Changes/Scale ZRAM to full memory size]] says that it's 8 GiB max, so not "100%". And we shouldn't blindly follow Fedora either, their change reasoning is not always properly documented. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:05, 24 June 2023 (UTC)<br />
<br />
== "2.2 Install essential packages" needs more specific suggestions for absolute beginners. ==<br />
<br />
I personally had a lot of problems with the installation and had to resort to "walk-throughs" that just caused hours of headaches. I will point out some of the problems I had with this section.<br />
<br />
"userspace utilities for the management of file systems that will be used on the system" <br />
is wordy and vague. It is unhelpful to someone completely new. The hyperlink points to types of file systems which is not intuitive to the statements suggestion. At the very least, "userspace utilities" should be hyperlinked to a section of programs the statement is suggesting. Several months on, I still am unsure of what they are eluding to.<br />
<br />
"specific firmware for other devices not included in linux-firmware (e.g. sof-firmware for sound cards)"<br />
An absolute beginner does not know what specific firmware are not included in linux-firmware. The suggestion of sound cards is extremely outdated, and frankly makes it seem like linux-firmware is going to leave you needing a lot of drivers if it cannot even operate your sound card out of the box. This confusion led me down a rabbit hole of installing(or trying to find) CPU microcode updates, nvidia drivers, wired or wireless drivers, motherboard drivers, and so on.<br />
<br />
"software necessary for networking (e.g. a network manager or a standalone DHCP client, authentication software for Wi-Fi, ModemManager for mobile broadband connections)" My first problem was I was unaware of the need to systemctl enable the networking software, which led me to installing multiple DHCP clients and causing issues further down the road. I am now aware that if I had read more into the software. I believe a simple reminder to systemctl enable the networking software could save a lot of people problems. <br />
<br />
"a text editor,"<br />
The hyperlink just throws a list of 70 or so text editors at you. This is quite needlessly daunting to someone new. Even something as basic as "e.g. vim" would have spared me from being so overwhelmed this far into my troubles with this section. <br />
<br />
"packages for accessing documentation in man and info pages: man-db, man-pages and texinfo."<br />
This should take priority above all by being placed first in this list. <br />
<br />
I would recommend a section "2.2.1 Example(s) of essential packages" be created that shows at least one example of a typical users desktop computer, and what they would install on this step.<br />
<br />
{{Unsigned|21:12, 12 June 2023 (UTC)|Todd the king}}<br />
<br />
:I would refer you to https://wiki.archlinux.org/title/Arch_Linux#User_centrality. Arch's target audience isn't absolute beginners, it's experienced Linux users that know what they want and how they want their system set up. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 22:37, 12 June 2023 (UTC)<br />
<br />
::It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems. {{Unsigned|21:12, 12 June 2023 (UTC)|Todd the king}}<br />
<br />
:::And your argument is that you don't want to read the documentation. Arch dosen't make these decisions for you, you need to either know what you want or be willing to figure out what you want. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 22:49, 12 June 2023 (UTC)<br />
<br />
::::I did read the documentation, and I did figure out what I wanted. It took much longer than it should have because the instructions were hazy on this section. Why give any examples of software or suggestions of configuration to use in the article at all if this is the mindset of the guide? Where is the line and why? [[User:Todd the king|Todd the king]] ([[User talk:Todd the king|talk]]) 23:09, 12 June 2023 (UTC)<br />
<br />
:First of all, welcome :)<br />
:Now, I'm sorry but: <br />
<br />
::"userspace utilities for the management of file systems that will be used on the system" <br />
::is wordy and vague. It is unhelpful to someone completely new. The hyperlink points to types of file systems which is not intuitive to the statements suggestion. At the very least, "userspace utilities" should be hyperlinked to a section of programs the statement is suggesting. Several months on, I still am unsure of what they are eluding to.<br />
<br />
:The very first section of the linked page (i.e. [[File systems#Types of file systems]] has a table which helpfully has a "Userspace utilities" column, I fail to see how skipping the page introduction would make this more obvious. <br />
<br />
::"specific firmware for other devices not included in linux-firmware (e.g. sof-firmware for sound cards)"<br />
::An absolute beginner does not know what specific firmware are not included in linux-firmware. The suggestion of sound cards is extremely outdated, and frankly makes it seem like linux-firmware is going to leave you needing a lot of drivers if it cannot even operate your sound card out of the box. This confusion led me down a rabbit hole of installing(or trying to find) CPU microcode updates, nvidia drivers, wired or wireless drivers, motherboard drivers, and so on.<br />
<br />
:An absolute beginner's encouraged to seek help if he's unsure of what advice is applicable to its hardware. As shown in the tables in [[Laptop/Lenovo]], various recent laptops ''do'' require [[ALSA firmware]], while some models require specific drivers (and its respective firmware) for wireless networking: [[Broadcom wireless]], or even some USB3 chipsets on the motherboard with {{AUR|upd72020x-fw}} for example. <br />
<br />
::"software necessary for networking (e.g. a network manager or a standalone DHCP client, authentication software for Wi-Fi, ModemManager for mobile broadband connections)" My first problem was I was unaware of the need to systemctl enable the networking software, which led me to installing multiple DHCP clients and causing issues further down the road. I am now aware that if I had read more into the software. I believe a simple reminder to systemctl enable the networking software could save a lot of people problems. <br />
<br />
: Someone manually configuring a [[Network configuration#Static IP address|static ip connection]] would not need that step, while every dedicated [[network manager]] page explains the need for enabling their respective systemd unit. <br />
<br />
::"a text editor,"<br />
::The hyperlink just throws a list of 70 or so text editors at you. This is quite needlessly daunting to someone new. Even something as basic as "e.g. vim" would have spared me from being so overwhelmed this far into my troubles with this section. <br />
<br />
:Not picking a default text editor is a feature and not a bug: every choice made of a "sane default" would create endless bikeshedding (see [[Wikipedia:Editor war]]), although a popular beginner friendly one has been used as an example in [[Help:Reading#Append, add, create, edit]]. <br />
<br />
::"packages for accessing documentation in man and info pages: man-db, man-pages and texinfo."<br />
::This should take priority above all by being placed first in this list. <br />
<br />
:Man pages can be accessed with man.archlinux.org instead of wasting bandwidth and disk space by installing and updating a local version. <br />
<br />
::I would recommend a section "2.2.1 Example(s) of essential packages" be created that shows at least one example of a typical users desktop computer, and what they would install on this step.<br />
<br />
: This guide is not specific to desktop users, a dedicated section is out of scope. <br />
<br />
: As a general answer, our aim is to provide readers with the information they need to make an educated decision at every step, not rubber stamping the [https://pkgstats.archlinux.de/ popularity] of various software solutions. <br />
: While a little overwhelming at first, this approach has proven itself to be the best working on the long term: [[Help:Reading#Organization]]. <br />
: --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 00:07, 13 June 2023 (UTC)<br />
<br />
:I replaced "sound cards" with "onboard audio" which will hopefully get the message across better. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:56, 13 June 2023 (UTC)<br />
<br />
:After a bit of staring at [[Installation guide#Install essential packages]], I can confidentially say I can find some fault in each and any bullet point. So, starting from the top, I propose changing the first one to:<br />
::[[File systems|userspace utilities for file systems]] that will be used on the system—for the purposes of e.g. file system creation and [[fsck]],<br />
: It gets rid of the vague "for the management" and adds actual reasons for wanting the userspace utilities.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:37, 13 June 2023 (UTC)<br />
<br />
::Since no one objected, and I finally remembered this discussion, I updated the page per my suggestion above. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:06, 22 June 2023 (UTC)<br />
<br />
:"utilities for accessing [[RAID]] or [[LVM]] partitions" could be replaced with something like:<br />
::utilities for accessing and managing [[RAID#Installation|RAID]] or [[LVM#Installation|LVM]] if they will be used on the system,<br />
:These things can actually be ''managed'', and they are not limited to ''partitions''. Also IMO it's better to directly link to the section that lists the packages to install.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:48, 22 June 2023 (UTC)<br />
<br />
::[[Special:Diff/782222|Done]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:23, 30 June 2023 (UTC)<br />
<br />
:On to the next one:<br />
::specific firmware for other devices not included in {{Pkg|linux-firmware}} (e.g. {{Pkg|sof-firmware}} for [[Advanced Linux Sound Architecture#ALSA firmware|onboard audio]], {{Pkg|linux-firmware-marvell}} for Marvell wireless and any of the multiple firmware packages for [[Broadcom wireless]]),<br />
:It lists the only split-package of {{Pkg|linux-firmware}} that I've heard anyone actually need and also the dreaded Broadcom wireless.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:23, 30 June 2023 (UTC)<br />
<br />
::Since no one has stopped me yet: [[Special:Diff/782857]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:20, 9 July 2023 (UTC)<br />
<br />
:I do not think the "software necessary for networking" bullet point lacks anything. Instead, [[Installation guide#Network configuration]] could be improved to avoid giving the impression that ''installing'' a piece of software is enough to make it operational. Unfortunately I can't think of a good, easily digestible phrase that accomplishes that. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:27, 9 July 2023 (UTC)<br />
<br />
::Best I can come up for [[Installation guide#Network configuration]] is:<br />
:::That may include installing suitable [[network management]] software, configuring it if necessary and enabling its systemd unit so that it starts at boot.<br />
::Thoughts?<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:04, 15 August 2023 (UTC)<br />
<br />
:::I would slightly alter the order of the words: <br />
::::That may include installing suitable [[network management]] software, configuring it and enabling its systemd unit so that it starts at boot if necessary.<br />
:::Outside of that minor nitpick, it is probably beneficial to be explicitly pointing out commons steps instead of hoping people will read the Wiki page of every software they install :P --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 10:38, 15 August 2023 (UTC)<br />
<br />
::::The thought was that you need to install the package and enable the unit, but configuring is not always required. E.g. NetworkManager & dhcpcd can be simply be used as is for Ethernet connections with no prior configuration. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:42, 15 August 2023 (UTC)<br />
<br />
:::::👍 --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 11:02, 15 August 2023 (UTC)<br />
<br />
::::::[[Special:Diff/786476|Done]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:04, 30 August 2023 (UTC)<br />
:I think it would be better if "a [[text editor]]" would instead say "a console [[text editor]]", since you won't be able to use graphical ones in the tty. The issue with that text is that [[List of applications#Vi-style text editors]] and [[List of applications#Emacs-style text editors]] are separate sections on the same level as "console" and "graphical". -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:35, 23 October 2023 (UTC)<br />
::And linking to [[List of applications#Console 23]] would skip the vi/emacs-style editors so it's not an option either :/ -- [[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 11:41, 23 October 2023 (UTC)<br />
<br />
== Default mount permissions for ESP are insecure for systemd-boot ==<br />
<br />
I suggest editing the `Mount_the_file_systems` section and adding explicit permissions to the mount that will remove world readability from the ESP.<br />
<br />
The removed file and directory masks seem to be `fmask=0022,dmask=0022`, what should instead be suggested is to at least remove world with `fmask=0027,dmask=0027`.<br />
<br />
When using a bootloader like systemd-boot, which puts secrets `ESP/loader/random-seed`, it will complain that the mountpoint and the file itself have world-readable permissions, see https://t.me/archlinuxgroup/690016 for screenshot.<br />
<br />
Per-file permissions are impossible as the only supported file system by default as per UEFI spec is FAT.<br />
<br />
This should ALSO be mentioned in the [[Systemd-boot]] page.<br />
<br />
Perhaps just add it there and make a note in the installation guide "if using systemd-boot as a bootloader..."? I am not sure if this is a problem with other bootloaders.<br />
<br />
<br />
[[User:C0rn3j|C0rn3j]] ([[User talk:C0rn3j|talk]]) 19:17, 15 October 2023 (UTC)<br />
<br />
:There's an existing discussion about the topic in [[Talk:EFI system partition#Mountpoint umask]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:42, 16 October 2023 (UTC)<br />
<br />
== <s>change ping archlinux.org to ping -c 3 archlinux.org</s> ==<br />
<br />
that way it stops pinging [[User:Matthewq337|Matthewq337]] ([[User talk:Matthewq337|talk]]) 19:41, 13 November 2023 (UTC)<br />
<br />
:The [[ping]] link already leads to instructions how to stop it. See also [[Special:Diff/731818#Ping endless]] [[User:Andreymal|andreymal]] ([[User talk:Andreymal|talk]]) 19:51, 13 November 2023 (UTC)<br />
<br />
== <s>localectl list-keymaps works</s> ==<br />
<br />
[[#Read this first before adding new suggestions]] says "{{ic|localectl list-keymaps}} does not work due to bug {{Bug|46725}}".<br />
<br />
I won't pretend to understand [https://github.com/torvalds/linux/blob/master/fs/overlayfs/inode.c fs/overlayfs/inode.c], but from what I can guess, while [https://lore.kernel.org/all/1479133374-9292-1-git-send-email-quorum.laval@gmail.com/ the patch] was never merged, some other changes over the years resulted in it having the same effect.<br />
<br />
I propose using {{ic|localectl list-keymaps}} in [[Installation guide#Set the console keyboard layout and font]].<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:20, 15 November 2023 (UTC)<br />
<br />
:👍 Since it works now :)<br />
:-- [[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 10:00, 15 November 2023 (UTC)<br />
<br />
:👍 Since it works now :) — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:32, 21 November 2023 (UTC)<br />
<br />
::[[Special:Diff/793695|Implemented]]. "pass its name" was probably not the prettiest way to word it, but it'll do for now. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:38, 1 December 2023 (UTC)<br />
<br />
:::Please update the notes in [[#Read this first before adding new suggestions]] as well. I don't know if the warning still applies to other *ctl tools. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:07, 2 December 2023 (UTC)<br />
<br />
== <s>Use localectl set-keymap</s> ==<br />
<br />
Instead of using {{ic|loadkeys}} in [[Installation guide#Set the console keyboard layout and font]] and manually editing {{ic|/etc/vconsole.conf}} in [[Installation guide#Localization]], I propose instructing to use {{ic|localectl set-keymap}}.<br />
<br />
Unlike ''loadkeys'', ''localectl'' writes to {{ic|/etc/vconsole.conf}} so it's persistent. It also writes {{ic|XKBLAYOUT}}, {{ic|XKBMODEL}}, {{ic|XKBVARIANT}} and {{ic|XKBOPTIONS}} which maybe will be used by something in the future.<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:53, 1 December 2023 (UTC)<br />
<br />
:What is the value of "persistent" in this case? The file {{ic|/etc/vconsole.conf}} only applies to the live system. There is {{ic|--machine}} but it only works with [[systemd-nspawn]] containers. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:59, 2 December 2023 (UTC)<br />
::Yeah, there's no value for it in the live system. And since you need to configure {{ic|FONT{{=}}}} manually anyway (which [[Installation guide#Localization]] doesn't even mention), there's probably no reason to change things for now. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:13, 3 December 2023 (UTC)<br />
<br />
== <s>Mention POSIX compatibility in list of packages for consideration to installation</s> ==<br />
<br />
Please mention {{Pkg|posix-user-portability}} in the list of packages for user's consideration of installation<br />
<br />
-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 16:41, 2 December 2023 (UTC)<br />
<br />
:Why? I have never installed this package and have not experienced any problems, which means that this package is clearly not essential. — [[User:Andreymal|andreymal]] ([[User talk:Andreymal|talk]]) 17:21, 2 December 2023 (UTC)<br />
::I mean, I never installed e.g. utilities for accessing and managing RAID or LVM, yet they are on the list. <br />
::Man pages also aren't essential, yet are listed. Software for networking also technically isn't essential. <br />
::Since this is list of packages to consider, I think it would be nice to know upfront about something potentially missing instead of when a script breaks due to lacking utility.<br />
::-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 17:46, 2 December 2023 (UTC)<br />
:👎 from me, we don't advertise being POSIX-compatible by default, nor is this a common issue I've seen users being bitten by. <br />
:-- [[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 17:35, 2 December 2023 (UTC)<br />
::Of course, that why I'm not asking to include it in {{Pkg|base}} package, but putting it here so users are explicitly aware during installation some standard utilities may be missing.<br />
::-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 17:48, 2 December 2023 (UTC)<br />
<br />
::Having this package installed is not a common expectation, as demonstrated by its recent addition in 2020. The base package (and base group before that) has been around for over a decade. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:06, 2 December 2023 (UTC)<br />
:::Could we have at least an explicit warning about it somewhere?<br />
:::Most popular utilities are already pulled as dependencies for other packages, so users don't notice.<br />
:::But they may sooner or later want to use a script from outside repos, which needs a (standard) utility not installed as dependency for something else.<br />
:::-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 20:38, 2 December 2023 (UTC)<br />
::::Then they can just install packages they need. I don't see any need to add a warning. — [[User:Andreymal|andreymal]] ([[User talk:Andreymal|talk]]) 20:50, 2 December 2023 (UTC)<br />
:::::Because, for better or worse, users of *nix systems usually expect those utilities being present by default.<br />
:::::It's really not nice when your POSIX compliant script suddenly breaks due to missing utility (and borks files).<br />
:::::<small><sup>(Yes, I'm speaking from experience; no, I don't remember which utility it was - I had this suggestion on my TODO list for over half a year; yes, technically I could've deduced that from the bullet about text editor, but it's not so obvious)</sup></small><br />
:::::-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 21:35, 2 December 2023 (UTC)<br />
:::::: Are you seriously arguing that everyone should be installing telnet, s-nail, ed, pax, etc? No. Just no. Even cronie is silly on a systemd system. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 04:50, 3 December 2023 (UTC)<br />
:::::::I really don't know how did you reach such a conclusion. Of course I don't argue for that.<br />
:::::::On this page is step [[Installation guide#Install_essential_packages|2.2 Install essential packages]], where there are words "In particular, consider installing:" after which is a list of packages a user might want to install.<br />
:::::::Second point from that list ("utilities for accessing and managing RAID or LVM if they will be used on the system") clearly shows, those aren't mandatory packages.<br />
:::::::Thus this list is a perfect place to inform user that {{Pkg|base}} package doesn't contain standard POSIX utilities and they need to install them extra if they desire.<br />
:::::::-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 05:24, 3 December 2023 (UTC)<br />
::::::::Read you quoted sentence until the end: "if they will be used on the system": they are present on the live media and will not be automatically installed after setting up the RAID, preventing boot and thus qualifying as "essential".<br />
::::::::The common advice for users when wanting to install a package from outside the repositories is to create a PKGBUILD for it, which should allow catching missing dependencies at that point. <br />
::::::::I'd be really interested in which tool was missing for you, as {{Pkg|posix-user-portability}} is simply a meta-package depending on {{Pkg|cronie}}, {{Pkg|inetutils}}, {{Pkg|posix}}, {{Pkg|util-linux}} and {{Pkg|vi}}, it feels excessive to point people to install a whole array of packages if they're only missing a single one. <br />
::::::::Maybe this could be a new subsection in [[General recommendations#Console improvements]], to explicitly explain we are only ''mostly'' POSIX compatible by default, and people who require it can install the meta-package to fit that need? <br />
::::::::-- [[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 08:24, 3 December 2023 (UTC)<br />
:::::::::It wasn't being installed as external package, just regular user shell script; simple <code>chmod +x script && ./script</code>. The only expectation were standard POSIX utilities.<br />
:::::::::I'm pretty sure the missing one was something very basic, like {{Pkg|bc}} or {{Pkg|ex}}.<br />
:::::::::Installing whole array of packages may feel excessive for one script, but if you have multiple of them, then the whole point of the standard is to have this bare minimum not to worry about.<br />
:::::::::So well, I guess putting it in [[General recommendations]] may also be a good place. Always better than learning that when something breaks.<br />
:::::::::-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 10:29, 3 December 2023 (UTC)<br />
<br />
== Mention that partitionning is more-or-less permanent ==<br />
<br />
While there are solutions to reformat/repartition drives after the fact, it should be made obvious (warning/info box?) that changing partitions after a system is installed can be a major PITA. I've seen too many reddit support posts about wanting to add more space to the root partition or encrypting everything after the fact.<br />
<br />
Therefore, I suggest adding in [[Installation guide#Partition the disks|section 1.9]]:<br />
<br />
{{Warning|Re-partitioning disks after the fact is difficult and involves moving data and system around. It is therefore recommended to properly size and format disks, according to: [[Partitioning]]. If you need disk encryption, now is the time to look into [[Data-at-rest_encryption]].}} [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 18:05, 5 December 2023 (UTC)<br />
<br />
:Yeah, for once this probably deserves a warning instead of a note since it's "reasonably difficult" to fully reinstall a system to add encryption after the fact.<br />
:Maybe we could simply expand on the existing <br />
:"If you want to create any stacked block devices for LVM, system encryption or RAID, do it now." sentence?<br />
:-- [[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 06:20, 6 December 2023 (UTC)<br />
:If the issue in an under-provisioned root partition, then we can simply add the recommended size (32 GiB) to the tables in [[Installation guide#Example layouts]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:45, 6 December 2023 (UTC)<br />
::This only solves part of the issue. The part about encrypting the device/partitions after the fact is still not covered. [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 10:11, 6 December 2023 (UTC)</div>Moviurohttps://wiki.archlinux.org/index.php?title=Talk:Installation_guide&diff=793955Talk:Installation guide2023-12-05T18:05:47Z<p>Moviuro: /* Mention that partitionning is more-or-less permanent */ new section</p>
<hr />
<div>== Read this first before adding new suggestions ==<br />
<br />
* systemd tools such as ''hostnamectl'', ''timedatectl'' and ''localectl'' [https://github.com/systemd/systemd/issues/798#issuecomment-126568596 do not work] in the installation chroot environment, so please do not propose to use them in the guide unless you can prove that they have been made to work also in that case. See [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=388727#General_problems], [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=404695#Replace_commands_with_their_systemd_equivalents], [https://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&oldid=418662#Utilizing_systemd_tools] and [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=434985#change_configuration_system_from_old_way_to_new_way.28using_systemd_commands.29] for some past discussions about this issue.<br />
* Due to the wide variety of available boot loaders, the installation guide refers to [[Arch boot process#Boot loader]] instead of making a specific recommendation for the installed system. See [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=687325#Bootloader], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=690612#Make_the_Boot_Loader_Section_slightly_more_detailed_to_provide_a_high_level_overview_for_new_users], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=678949#Expand_Boot_loader_section], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=660151#Expand_Boot_loader_section_to_include_example_commands], [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=581427#Boot_loader_installation] for some past discussions on this topic.<br />
* While [[:Category:Installation process]] lists additional installation methods (e.g. [[archinstall]] or [[systemd-firstboot]]), the installation guide does not reference them due to their specific nature. [[Install Arch Linux with accessibility options]] is an exception. See [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=698307#Point_out_archinstall] for past discussion on this topic.<br />
-- [[ArchWiki:Administrators|The ArchWiki Administrators]] 22:17, 2 September 2016 (UTC)<br />
__TOC__<br />
<br />
== Link to the German version ==<br />
<br />
Instead of [[de:Arch Install Scripts]] you could choose [[de:Anleitung für Einsteiger]] it means "Beginner's Guid" and is a very <br />
detailed artikel for very new arch users and the future experts.<br />
<br />
:Thank you, [https://wiki.archlinux.org/index.php?title=Installation_guide&type=revision&diff=509961&oldid=508505 done]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:31, 6 February 2018 (UTC)<br />
<br />
::This was already proposed last year and rejected: [https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=466950#Suggesting_different_page_for_German_translation]. I don't see what has changed since then. If someone adds me as admin to the german wiki or changes the protection settings, I can update [[de:Arch Install Scripts]] as required. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:13, 6 February 2018 (UTC)<br />
<br />
:::I see, I didn't remember that discussion so I've reverted the change, hopefully you'll make it to update the translation, let's leave this open until the problem is solved, otherwise this kind of suggestion will keep appearing recurrently. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:53, 7 February 2018 (UTC)<br />
<br />
::::Apparently since last year the translation has been halved in size, but its scope is still much larger than the [[Install guide]] (or even the old [[Beginners' guide]]). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 9 May 2021 (UTC)<br />
<br />
== First mention of /mnt in example partition layout ==<br />
<br />
{{ic|/mnt}} is mentioned at mount point in [[Installation_guide#Partition_the_disks]], while {{ic|/mnt}} is made explicit two sections later in [[Installation_guide#Mount_the_file_systems]]. As I recall it, this was changed because some users blindly copy pasted commands and mounted /boot on the live system, instead of /mnt/boot. Some options:<br />
<br />
* Introduce another column describing the mount point on the installed system. <br />
* Actually explain /mnt early.<br />
* Revert the "mount point" to not include /mnt.<br />
<br />
-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 13:03, 7 September 2019 (UTC)<br />
<br />
:I don't understand what's the actual problem here... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:36, 8 September 2019 (UTC)<br />
<br />
::From what I read on [[ArchWiki:IRC|#archlinux-wiki]], this comes from https://www.reddit.com/r/archlinux/comments/d0v0j3/is_it_just_me_or_is_the_prospect_of_installing/ where the user was confused by the lack of root mountpoint (i.e. {{ic|/mnt}} vs {{ic|/}}). A question could be raised, if we should concern ourselves with users who have strong opinions about the wiki content yet can't be bothered to propose improvements in the talk pages...<br />
::About Alad's proposed options: I disagree with the first option, I think it will just complicate things even further. I support the third option and maybe adjusting the column header like in [[Special:Diff/581800]].<br />
::I'd actually would like to go even further and change the commands run from outside chroot to be visually distinct, e.g.: {{bc|1=<span style="color: #ff0000;">root@archiso #</span> mount /dev/sd''X1'' /mnt}}<br />
::I think it would better solve the underlying issue. <br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:26, 8 September 2019 (UTC)<br />
<br />
:::I'm not overly fond of the longer column name. For the last proposed option, I may agree if this is formalized in [[Help:Style]], so that it is not specfic to the [[Installation guide]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:20, 10 September 2019 (UTC)<br />
<br />
::::Adding it [[Help:Style]] was my intention, since other articles, too, will need to use that style for some commands. I'm thinking of creating a template for it: [[Special:Permalink/581945]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:19, 11 September 2019 (UTC)<br />
<br />
:::::Sounds good to me, I'd just prefer the regular (non-bold) font for the prompt as above. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:54, 13 September 2019 (UTC)<br />
<br />
::::::[[Special:Permalink/582327]]. Are there any other opinions about creating such a template? Or should I take this discussion to [[Help talk:Template]] per [[Help:Template#Creation]]? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 18:31, 14 September 2019 (UTC)<br />
<br />
:::::::# How are you going to call the template? This template would probably add to the [[Help:Template#Code formatting templates]] series, should it be named in a consistent fashion?<br />
:::::::# Should this template support custom prompts, and if so, should it be called "pc" (from "(custom) prompted" code)?<br />
:::::::# I don't like the red color too much, if bold is not an option maybe we can go green|purple|blue, something that recalls less a warning of some kind? Or can we just leave it with the default font color? Or a slightly fainter black?<br />
:::::::# I haven't looked well into it, but maybe we can instead add an optional argument to [[Template:bc]] and [[Template:hc]] that prefixes a custom (colored) prompt? I wouldn't see a problem with repeating "root@archiso #" in every instance, or we may derive the new template from those two at that point.<br />
:::::::# The template should probably be derived from [[Template:bc]] in any case, for simpler code, see [[User:Kynikos/Template:Sandbox2]].<br />
:::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 17:36, 16 September 2019 (UTC)<br />
<br />
::::::::# Initially I was going to call it [[Template:Archiso]] since it would be [[Archiso]]-specific, but I'm starting to think that creating a more general-purpose template would be better. It could then be used in [[PostgreSQL]] and the {{ic|[postgres]$}} convention would get formalized in [[Help:Style]]. Now the issue is the {{ic|[user@peer-a]#}} in [[Template:hc]] used in [[WireGuard]]. I'd rather not create two new templates, but I'm having trouble getting [[Template:Sandbox]] to work :(<br />
::::::::# I like your "[[Template:pc]]" suggestion.<br />
::::::::# Be glad I didn't post my first draft that was ''slightly more'' colorful. From your offered colors, I'd choose purple.<br />
::::::::# I'd rather not mess with the established templates just for this change, so I'd prefer creating a new template.<br />
::::::::# I didn't even think about using [[Template:bc]]. Is it a good idea to do that? The new template might need to be updated if [[Template:bc]] is ever changed in an incompatible way.<br />
:::::::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:33, 17 September 2019 (UTC)<br />
<br />
:::::::::Yeah, after viewing your attempts and looking into it myself, I think modifying bc/hc is out of discussion, it would add too much code/style for so little use.<br />
:::::::::Thinking about this again one day after, I feel I'm realizing that my concerns in general may descend from the fact that we're going to create a template to represent (block) code, even though we already have 2 which basically do the same thing, including allowing to include a prompt; the only addition of this "Archiso" or "pc" template would be the formatting around the prompt, so why not keep it simple (I know, "simplicity" is often subjective and controversial) and instead either make a [[Template:Archiso]] to be used like {{ic|<nowiki>{{bc|{{Archiso}} mount /dev/sdX1 /mnt}}</nowiki>}} or [[Template:ps]] (or [[Template:PS]]) to be used like {{ic|<nowiki>{{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}</nowiki>}}? They also work with [[Template:hc]] and space-prefixed code blocks!<br />
:::::::::Putting the choice of color aside, if the above idea of a standalone prompt template isn't welcome, I think my second choice would be to make two [[Template:pbc]] and [[Template:phc]] that work like {{ic|<nowiki>{{pbc|$|ls}}</nowiki>}} and {{ic|<nowiki>{{phc|$|ls|...}}</nowiki>}}, with the style rule to use them only in case of complex prompts. I'd still derive them from bc/hc to inherit any changes that we'd decide to make to them, and avoid repeating that ugly &lt;pre> hack even more.<br />
:::::::::Otherwise I give up and accept the [[Template:Archiso]] that works like {{ic|<nowiki>{{Archiso|mount /dev/sdX1 /mnt}}</nowiki>}}, in the hope that one day we won't need an analogous "hc" version.<br />
:::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:24, 17 September 2019 (UTC)<br />
<br />
::::::::::I can't say I really like the idea of {{ic|<nowiki>{{bc|{{Archiso}} mount /dev/sdX1 /mnt}}</nowiki>}} or {{ic|<nowiki>{{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}</nowiki>}}. I'd prefer creating [[Template:pbc]] and [[Template:phc]].<br />
::::::::::I still don't get what's wrong with [[Template:Sandbox]]. It should just work:<br />
<br />
<pre<noinclude></noinclude> {{#if: code|style="margin-bottom: 0; border-bottom:none; padding-bottom:0.8em;"}}>prompt # command</pre<noinclude></noinclude>><noinclude><!-- The &lt;noinclude>&lt;/noinclude> hack is needed to allow wiki markup inside the pre tags; reference: http://www.gossamer-threads.com/lists/wiki/mediawiki/118688#118688 --><br />
{{#if: code|<pre<noinclude></noinclude> style="margin-top: 0; border-top-style:dashed; padding-top: 0.8em;">code</pre<noinclude></noinclude>>}}<br />
<br />
:::::::::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 04:43, 18 September 2019 (UTC)<br />
<br />
:::::::::::FWIW (and a bit of fun) I've fixed [[Template:Sandbox]], although I'm not sure if we really need that level of automation ^^ I stick to my position above, is there a third (or more) opinion? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:48, 18 September 2019 (UTC)<br />
<br />
:::::::::I think you like the [https://wiki.archlinux.org/index.php?title=User_talk:Nl6720&diff=447834&oldid=447833 #800080] shade of purple, right? ;-) [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:39, 21 September 2019 (UTC)<br />
<br />
::::::::::Yes, I do like that one :D but I think it would be too bright for this template. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:52, 21 September 2019 (UTC)<br />
<br />
:::::::::::Any news on this one? If not, I haven't seen this kind of issue or confusion occur since. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:37, 31 October 2021 (UTC)<br />
<br />
::::::::::::I don't think I want to create such a template anymore, since it would require updating other installation related pages. To go back to your originally proposed options, I'm for explaining {{ic|/mnt}} early. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:42, 4 November 2021 (UTC)<br />
<br />
== Buggy graphics driver ==<br />
<br />
Can there be a hint that nomodeset parameter could be used if the graphics driver is buggy (I've heard nouveau may be buggy sometimes)<br />
[[User:M.Srikanth|M.Srikanth]] ([[User talk:M.Srikanth|talk]]) 04:47, 12 May 2020 (UTC)<br />
<br />
:I would expect this to be mentioned in [[General_troubleshooting]]... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:43, 31 October 2021 (UTC)<br />
<br />
== GitLab blobs in Lynx ==<br />
<br />
Links to files (blobs) on gitlab.archlinux.org are not readable in Lynx (or any other console web browser); see https://gitlab.com/gitlab-org/gitlab/-/issues/26567.<br />
<br />
Should the Installation guide link to raw files instead?<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:29, 4 August 2020 (UTC)<br />
<br />
:Maybe you could ask svenstaro to add it to https://gitlab.com/gitlab-org/gitlab/-/issues/232073... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:36, 4 August 2020 (UTC)<br />
<br />
::It has been filed under [https://gitlab.com/gitlab-org/gitlab/-/issues/232073#nice-to-have nice to have]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:19, 4 August 2020 (UTC)<br />
<br />
:::Instead of using raw links we should perhaps consider if we need links to gitlab at all. The guide has:<br />
:::* [https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/blob/master/docs/README.bootparams README.bootparams]<br />
:::* <s>[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-ethernet.network Ethernet]</s><br />
:::* <s>[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wlan.network WLAN]</s><br />
:::* <s>[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wwan.network WWAN]</s><br />
:::* <s>[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/xdg/reflector/reflector.conf reflector.conf]</s><br />
:::* <s>[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64 packages.x86_64]</s><br />
:::Notice how all but one of these share the common path [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng archiso/-/blob/master/configs/releng]. Unless this level of specificity is really required, we could link to this path "for an overview of configuration files shipped with archiso" instead. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:35, 31 October 2021 (UTC)<br />
<br />
::::I'd prefer simply removing some of the links.<br />
::::* [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-ethernet.network Ethernet], [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wlan.network WLAN] and [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wwan.network WWAN] don't provide much value here, so they can be moved to [[systemd-networkd#Configuration examples]].<br />
::::* [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/xdg/reflector/reflector.conf reflector.conf] is there just for citation purposes. The [[reflector]] article already explains how the software works.<br />
:::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:30, 4 November 2021 (UTC)<br />
<br />
::::: Alright, I've removed those links. ([[Special:Diff/700696]], [[Special:Diff/700693]]) -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:39, 4 November 2021 (UTC)<br />
<br />
::::: Now that mirrors provide a symlink to the latest ISO version, it's possible to link to {{ic|pkglist.x86_64.txt}}. [[Special:Diff/730318|I replaced packages.x86_64 with it]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:31, 21 May 2022 (UTC)<br />
<br />
:Is Lynx (un)readability such a big problem in this case? People using Lynx from the archiso can open up the relevant file in the live system itself... — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:05, 31 October 2021 (UTC)<br />
<br />
== Post-installation ==<br />
<br />
I skipped steps in the guide so I faced a weird crash in gnome without any explanations. I suggest a note.<br />
<br />
{{Note|Many of them assume that you have your timezone or locales set up. Make sure you have followed all the steps.}}<br />
<br />
[[User:Escope|Escope]] ([[User talk:Escope|talk]]) 10:11, 2 April 2021 (UTC)<br />
<br />
:The reader is supposed to follow all the steps. If we apply that to other pages, the pages need a boatload of notes to make sure the reader did not skip any steps. A common functional system has properly configured locales and timezones.<br />
:Since this is GNOME-specific however I would at most add a section into [[GNOME/Troubleshooting]] or even [[General troubleshooting]], but I still think this is out of scope to be honest. Many applications may not work properly when the timezones or locales are not correctly configured.<br />
:-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 15:30, 2 April 2021 (UTC)<br />
<br />
::The reader is not supposed to follow all the steps in case one doesn't worthy of attention. In my humble opinion, that's why it has huge advantage over the "Next-Next-Finish" approach. Unconfigured locales or timezones are obvious to many people, but my inexperience made me spend some time to sorting out. The other pages are highly deep and clear about the steps and why they are needed, my eyes enjoy such notes, pages are boatloaded already and I like it a lot =D. Thank you for your attention to this little change.<br />
<br />
::-- [[User:Escope|Escope]] ([[User talk:Escope|talk]]) 00:23, 3 April 2021 (UTC)<br />
<br />
:::If you're inexperienced, what makes you think you can judge if a step is necessary or not? You thought you knew better than the people that wrote the guide and found out that you didn't. Not something that needs changed here IMO.<br />
:::[[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 01:57, 3 April 2021 (UTC)<br />
<br />
:::The ArchWiki should also be about the why-aspect. I am in favor of adding e.g a note about why they are needed and why some applications may crash or behave strangely without properly configured timezones/locales. If you know e.g a nice blog post about this topic, why not add something like this?<br />
:::{{Note|Some applications may behave in strange ways or even crash when the timezones and/or locales are not properly configured. See [https://xkcd.com/1084/ this informative blog post] to know why that is.}}<br />
:::The note needs obviously some rewording, but something like this would fit in well in my opinion.<br />
:::-- [[User:NetSysFire|NetSysFire]] ([[User talk:NetSysFire|talk]]) 02:02, 3 April 2021 (UTC)<br />
<br />
::::Adding a '''brief''' "why" would be ok, but using [[Template:Note]] would be too much. I've also always wanted to emphasize the "and" in [[Installation guide#Localization]], since it's easy to miss (even some of the translated installation guides do not mention {{ic|en_US.UTF-8 UTF-8}}). --- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:48, 3 April 2021 (UTC)<br />
<br />
:::::People who want to know the "why" can already consult the relevant articles. That said, consistency is lacking: some sections explain in detail why a step should be performed (such as [[Installation_guide#Verify_signature]]), whereas [[Installation_guide#Configure_the_system]] is mostly a checklist of steps with brief instructions how. The solution isn't obvious: adding notes all over would likely more distract than clarify. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:41, 14 April 2021 (UTC)<br />
<br />
::::::I'm definitely apposed to adding notes, but I don't see why we couldn't add brief "why"s without them. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:55, 15 April 2021 (UTC)<br />
<br />
== Note on Network Setup ==<br />
<br />
One of the most common installation issues that comes up on Reddit, Forums, and other discussion areas is not having done any sort of network setup. While the Installation Guide explicitly call out Network Setup as a required step, I suspect people are mistakenly believing the setup steps they did already to establish a connection on the installer will carry over to their installed system. <br />
<br />
I propose adding a note such as (example content):<br />
<br />
{{Note| Configuring your network connection above only established your network for the installer. This section will configure the network for your installed Arch system. Failure to do so may leave you without network access after completing installation.}} [[User:Nalthien|Nalthien]] ([[User talk:Nalthien|talk]]) 17:40, 15 May 2022 (UTC)<br />
<br />
:Such a thing [[Help:Style#Notes, Warnings, Tips|does not warrant a warning]] since there's nothing dangerous about being offline. It may even be the safest state the system will ever be. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:24, 18 May 2022 (UTC)<br />
<br />
:: I can agree that it doesn't warrant a Warning given the style guide; however, I do think a Note would be appropriate to "highlight information easily overlooked." It's clearly overlooked quite often. [[User:Nalthien|Nalthien]] ([[User talk:Nalthien|talk]]) 17:36, 20 May 2022 (UTC)<br />
<br />
:[[Installation guide#Connect to the internet]] already explains (or tries to, at least) that the live environment's network setup has nothing to do with the installed system. Perhaps the list items in [[Installation guide#Install essential packages]] could be made a little more verbose to explain '''why''' someone may want to install those things. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:24, 18 May 2022 (UTC)<br />
<br />
I propose adding something like the following:<br />
<br />
''To configure the freshly installed system's network for out-of-the-box ethernet DHCP functionality as on the installation image, create a simple /etc/systemd/network/20-wired.network file for your adapter Name, eg:''<br />
<br />
[Match]<br />
<br />
Name=enp1s0<br />
<br />
[Network]<br />
<br />
DHCP=yes<br />
<br />
''Also, enable both systemd-networkd.service and systemd-resolved.service''<br />
<br />
1. It will only take up a few lines; it is succinct, effective and informative. <br />
2. Further, the functionality on reboot will mimic functionality in the installation image.<br />
3. It uses simple built-in services without installing anything extra. <br />
4. It will also cut down on forum noise immensely.<br />
[[User:Misfit138|Misfit138]] ([[User talk:Misfit138|talk]] 11:11 21 March 2023 (UTC-5)<br />
<br />
: It's also incomplete, as systemd-resolved takes some setup. And it would cause more problems on the forums when people then enable NM or whatever and have both. There's a reason the network configuration page is linked. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 15:14, 21 March 2023 (UTC)<br />
<br />
:: systemd-resolved setup is optional according to the network configuration page, and I can confirm this to be the case on a bare-metal workstation as well as a VM. Doing the above minimal steps results in full functionality for a simple dhcp setup and mimics the ootb install image function. Further, installing NM as you indicated would result in a chicken or egg problem before reading a wall of text and realizing they have to setup a trivial and perhaps temporary dhcp solution in order to install a more permanent one anyway. The user has the ability to install packages in the chrooted environment, yes, but the expectation of a functional network in a freshly booted system is reasonable. One explanatory sentence or phrase can inform users that only one network config scheme is needed, as well as a brief warning to avoid conflicts (such warnings already exist elsewhere). The net conf. page can and should still be linked, but it is a monstrous page for something so trivial that can be suggested so succinctly. sent from my phone, will clean up formatting. -- [[User:Misfit138|Misfit138]] ([[User talk:Misfit138|talk]]) 11:37 22 March 2023 (UTC-5)<br />
<br />
:::systemd-networkd only supports using systemd-resolved for DNS. A network connection without working DNS is not something most people would want. I think the best we could do is to explicitly link to [[systemd-networkd]] as an example in [[Installation guide#Install essential packages]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:16, 22 March 2023 (UTC)<br />
<br />
::::With just the /etc/systemd/network/20-wired.network file, and no other network tools, and after starting networkd and resolved, I can ping sites and visit urls with links and lynx; ostensibly, something is resolving DNS for me(?) (Confirmed on VM and bare-metal.) However, I must regretfully admit that I am not likely to compel you with the principles I have set forth. Thank you for your time and for considering this. -- [[User:Misfit138|Misfit138]] ([[User talk:Misfit138|talk]]) 13:35 22 March 2023 (UTC-5)<br />
<br />
:::::I missed that you suggested to also enable {{ic|systemd-resolved.service}}. In that case, just as [[systemd-resolved#DNS]] says, DNS will only work for software that do not parse {{ic|/etc/resolv.conf}} themselves. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:44, 22 March 2023 (UTC)<br />
<br />
:Perhaps the "software necessary for networking" bullet point in [[Installation guide#Install essential packages]] could be extended with a tip that suggests using systemd-networkd + systemd-resolved and copying {{ic|/etc/systemd/network/20-ethernet.network}} from the live environment. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:18, 28 April 2023 (UTC)<br />
<br />
::The crosslinked article already has a note, that could be added there instead, similar to [[Special:diff/773727]]. <br />
::While I see the point of this item, the systemd- tools are probably not the most beginner-friendly ones to configure networking anyway (for some use-cases ok, not for the scope of this guide. Other tools like netctl are arguably simpler to use). The skill to configure networking is important and that's not triggered by copying an autogenerated file. What's the general state of [[archinstall]]? Could it be a solution to add a tip for Arch newcomers at the beginning of the guide to it instead?<br />
::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:45, 29 April 2023 (UTC)<br />
<br />
:::My idea was to ''somehow'' replace the note in [[Installation guide#Connect to the internet]] with a tip in [[Installation guide#Install essential packages]]. If there's no good way to do it, then let's keep things as is.<br />
:::archinstall would probably warrant an entirely separate discussion.<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:02, 30 April 2023 (UTC)<br />
<br />
== Missing pacman-key steps ? ==<br />
<br />
I just tried (using archlinux-2022.11.01-x86_64.iso) the standard archlinux installation (pacstrap) following the guide,<br />
and once the packages were downloaded, they failed to install with errors like:<br />
* "signature from <maintainer> is unknown trust"<br />
<br />
I found on the web the following commands to solve the issue: (https://bbs.archlinux32.org/viewtopic.php?id=2900)<br />
* pacman-key --init<br />
* pacman-key --populate archlinux<br />
<br />
After those two commands, the pacstrap installation works fine.<br />
<br />
If those two commands are needed, shouldn't we document them in the Installation guide ?<br />
<br />
(note that the same problem/solution is applicable to archinstall method too)<br />
<br />
{{Unsigned|23:02, 3 November 2022 (UTC)|Nsauzede}}<br />
<br />
:This is already done by pacman-init.service. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 23:38, 3 November 2022 (UTC)<br />
<br />
:I hit the exact same problem with same installation iso. I got the solution from https://wiki.archlinux.org/title/Pacman/Package_signing<br />
:{{Unsigned|2022-12-02T07:53:41|Roblaing}}<br />
<br />
: This is caused by out of date keyring, what really should be added to the installation guide is starting the keyring sync service {{ic|systemctl start archlinux-keyring-wkd-sync}} before the pacstrap step, with a warning to check that it has finished running before continuing. This will allow both older ISOs to work and even current ISOs to work. December ISO is once again broken right now as openssl has too new a key. [[User:C0rn3j|C0rn3j]] ([[User talk:C0rn3j|talk]]) 23:21, 24 December 2022 (UTC)<br />
::archlinux-keyring-wkd-sync doesn't 'sync' the keyring, it refreshes it which is only helpful in a limited set of circumstances. Most of the time, it won't help these errors. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 03:21, 25 December 2022 (UTC)<br />
::: It however helps with the current issue and am sure the previous issues too, as they were fixable with partially installing archlinux-keyring on the ISO before. I am not aware of a better solution, unless reinitializing and populating the keyring as per OP is actually preferred? [[User:C0rn3j|C0rn3j]] ([[User talk:C0rn3j|talk]]) 11:05, 25 December 2022 (UTC)<br />
::::Reinitializing and populating the keyring is a solution for a completely different problem. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 13:32, 25 December 2022 (UTC)<br />
<br />
== Add tip for easily booting iPXE-arch.efi file from almost all hardware ==<br />
<br />
For most scenarios (I assume) it isn't necessary to flash an USB drive or burn a disk.<br />
You can simply put the PXE EFI binary on a drive and boot it from "BIOS" directly (works e.g. on Dell hardware). If your BIOS does not support loading arbitrary files directly, you can use the UEFI shell to do so if available. Otherwise you can simply put the image under {{ic|/EFI/BOOT/}} and name it bootx64.efi and select this drive from the boot menu. The drive might even be the boot partition, if you are going to do a reinstall. (Tested on Lenovo and Fujitsu notebooks) [[User:Flacer|Flacer]] ([[User talk:Flacer|talk]]) 14:06, 26 January 2023 (UTC)<br />
<br />
:[[Installation guide#Acquire an installation image]] already mentions the netboot image. And yes, it should work just fine on any system with an Ethernet connection. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:13, 26 January 2023 (UTC)<br />
<br />
:: That is true, but in my opinion it would be beneficial to emphasize this because esp. new users think of setting up a server etc. (me too, although I'm not quite a new user; discovered this by accident).<br />
<br />
::So it would be better to put it under [[Netboot]]? Anyway it would be helpful to place a link to that page, most appropriately under 1.3. -- [[User:Flacer|Flacer]] ([[User talk:Flacer|talk]]) 15:42, 26 January 2023 (UTC)<br />
<br />
:::I could be wiki-linked from 1.1 and ''somehow'' mentioned in 1.3. Just need to find the right words for it. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:55, 1 February 2023 (UTC)<br />
<br />
::::I think an additional link in 1.1 is too early. Currently, the downloads landing page links a dedicated netboot page, which at the end leads to the wiki article. Linking it earlier may mislead to users skipping the gpg steps in 1.2. and the landing page.<br />
::::In 1.3 we could replace "or a network with [[PXE]]:" with "or an appropriate [[PXE]]" for starters. And complement that by adding to the last intro sentence in [[PXE]] "This works well when you already have a server set up, but may (for installation purposes) also load the image directly from an official Arch mirror."<br />
::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:52, 3 February 2023 (UTC)<br />
<br />
:::::I'm not too sure about "or an appropriate [[PXE]]". I assume most people would just place the netboot EFI binary in a USB flash drive and boot it directly. The fact that the images are iXPE builds is not that relevant. Perhaps 1.3 needs to explicitly differentiate the deployment methods of the ISO and netboot images since the links in the section are ISO specific. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:02, 4 February 2023 (UTC)<br />
<br />
::::::True, like two bullet points for ISO and iPXE in 1.3. I proposed "appropriate PXE", because (as Flacer mentions) current "network [[PXE]]" does indeed sound like you need to set up a server when you visit the article. How about switching [[PXE]] links to [[netboot]]?<br />
::::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:23, 5 February 2023 (UTC)<br />
<br />
:::::::Well, you can still PXE-boot the ISO contents as the [[PXE]] article describes, so I don't think it's correct to remove the links.<br />
:::::::I would probably be best if [[Netboot]] had instructions on how to create a bootable medium from the image. At least for UEFI, since that's dead simple. IMHO 1.3. could then be turned into two sentences, one for the ISO deployment, one for netboot.<br />
::::::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:52, 6 February 2023 (UTC)<br />
<br />
::::::::Sure, it can; see the sentence I proposed above for [[PXE]]. I agree it is more important to edit both articles first. The simple method proposed by Flacer can be turned into a tip in the [[Netboot]] section you suggest. Afterwards we can see what changes are still useful in this main guide. Perhaps this item should be moved to [[Talk:Netboot]] for implementation first. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:44, 16 February 2023 (UTC)<br />
<br />
:::::::::There's [[Netboot#Boot from a USB flash drive]] that can be linked now. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:10, 26 March 2023 (UTC)<br />
<br />
:::::::::I drafted something below. [[Installation guide#Boot the live environment]] will need adjustment too, so suggestions welcome. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:59, 24 June 2023 (UTC)<br />
<br />
::::::::::I added an draft for [[Installation guide#Boot the live environment]] below. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:05, 16 November 2023 (UTC)<br />
<br />
=== Prepare an installation medium (draft) ===<br />
<br />
The ISO can be supplied to the target machine via a [[USB flash installation medium|USB flash drive]], an [[Optical disc drive#Burning|optical disc]] or a network with [[PXE]]: follow the appropriate article to prepare yourself an installation medium from the ISO file.<br />
<br />
For the netboot image, follow [[Netboot#Boot from a USB flash drive]] to prepare a USB flash drive for UEFI booting.<br />
<br />
=== Boot the live environment (draft) ===<br />
<br />
{{Note|Arch Linux installation images do not support Secure Boot. You will need to [[Unified Extensible Firmware Interface/Secure Boot#Disabling Secure Boot|disable Secure Boot]] to boot the installation medium. If desired, [[Secure Boot]] can be set up after completing the installation.}}<br />
<br />
# Point the current boot device to the one which has the Arch Linux installation medium. Typically it is 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 />
# When the installation medium's boot loader menu appears,<br />
#* if you used the ISO, select ''Arch Linux install medium'' and press {{ic|Enter}} to enter the installation environment. <br />
#* if you used the Netboot image, choose a geographically close mirror from ''Mirror'' menu, then select ''Boot Arch Linux'' and press {{ic|Enter}}. {{Tip|<br />
#** The ISO uses [[GRUB]] for UEFI and [[syslinux]] for BIOS booting. Use respectively {{ic|e}} or {{ic|Tab}} to enter the [[Kernel parameters#Configuration|boot parameters]]. The Netboot image uses iPXE and the boot parameters can be specified in the ''Boot options'' menu. See [https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio-archiso/blob/master/docs/README.bootparams README.bootparams] for a list.<br />
#** A common example of manually defined boot parameter would be the font size. For better readability on HiDPI screens—when they are not already recognized as such—using {{ic|1=fbcon=font:TER16x32}} can help. See [[HiDPI#Linux console (tty)]] for a detailed explanation.<br />
#}}<br />
# You will be logged in on the first [[Wikipedia:Virtual console|virtual console]] as the root user, and presented with a [[Zsh]] shell prompt.<br />
<br />
To switch to a different console—for example, to view this guide with [https://lynx.invisible-island.net/lynx_help/Lynx_users_guide.html Lynx] alongside the installation—use the {{ic|Alt+''arrow''}} [[Keyboard shortcuts|shortcut]]. To [[textedit|edit]] configuration files, {{man|1|mcedit}}, [[nano#Usage|nano]] and [[vim#Usage|vim]] are available. See [https://geo.mirror.pkgbuild.com/iso/latest/arch/pkglist.x86_64.txt pkglist.x86_64.txt] for a list of the packages included in the installation medium.<br />
<br />
== Mention zram ==<br />
<br />
In [[Installation guide#Partition the disks]], The note mentions:<br />
<br />
:* [[Swap]] space can be set on a [[swap file]] for file systems supporting it.<br />
Should it be updated to add reference to [[zram]] as well ? Something like :<br />
:* As an alternative to a swap partition, [[Swap]] space can be set on a [[swap file]] for file systems supporting it, or in a [[Zram|compressed block device in ram]].<br />
<br />
-- [[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 23:04, 30 January 2023 (UTC)<br />
<br />
:I do not think zram is essential enough (compared to the defaults) for it to be mentioned in the [[Installation guide]], or even in [[General recommendations]]. The [[Improving performance|snake oil article]] references it and IMHO that's enough. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:22, 31 January 2023 (UTC)<br />
<br />
::(Re-opened, hope that's ok)<br />
::Certainly not essential, but it's one possible reason not to plan for a swap partition during the partitioning step. Distros like Fedora provide that [https://fedoraproject.org/wiki/Changes/SwapOnZRAM by default], it's a reasonable way to set up a system, I don't see any harm in mentioning it. People often read the installation guide many times before actually installing Arch, it's a perfect way to learn about possibilities, whereas [[Improving performance]] is probably most often read after installation on a running system. Swap files are already mentioned, so it doesn't require any extra note or clutter, just modifying a sentence, which is nice.<br />
::-- [[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 16:16, 31 January 2023 (UTC)<br />
<br />
:::If it were to be added to the installation guide, I want it to contain the phrase "swap on zram" instead of obfuscating it with "compressed block device in ram" or similar.<br />
:::I don't think we can link to [[Zram#Usage as swap]] unless it has a suggested size for the swap space.<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:13, 22 June 2023 (UTC)<br />
<br />
:: I was about to say, we can just link to the suggested size from the [[swap]] article but... there is no suggested size there either :)<br />
:: -- [[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 15:09, 22 June 2023 (UTC)<br />
<br />
:::There's [[Partitioning#Swap]], which IMO should be linked from [[Swap#Swap file]], but it doesn't actually say anything specific. Instead the recommended size is only listed in the [[Partitioning#Example layouts]] table.<br />
:::Still, does the general swap size recommendation apply to swap on zram? Is wasting 512 MiB of RAM enough?<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:24, 22 June 2023 (UTC)<br />
<br />
:: No you're right, the general swap size recommendation does not really apply to zram. A percentage of available RAM makes more sense. {{ic|zram-generator}} has a default of {{ic|1=zram-size = min(ram / 2, 4096)}}, Fedora uses [https://fedoraproject.org/wiki/Releases/34/ChangeSet#Scale_ZRAM_to_Full_Memory_Size 100%] of RAM. I've been using 100% without problems for quite a while. I would suggest 100% for regular desktop/laptop use, and 50% if having to deal with specific non compressible workloads (not sure what this would be though, I've had no problem with encoding of large video files, or such).<br />
:: -- [[User:Cvlc|Cvlc]] ([[User talk:Cvlc|talk]]) 16:50, 22 June 2023 (UTC)<br />
<br />
:::[[Fedora:Changes/Scale ZRAM to full memory size]] says that it's 8 GiB max, so not "100%". And we shouldn't blindly follow Fedora either, their change reasoning is not always properly documented. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:05, 24 June 2023 (UTC)<br />
<br />
== "2.2 Install essential packages" needs more specific suggestions for absolute beginners. ==<br />
<br />
I personally had a lot of problems with the installation and had to resort to "walk-throughs" that just caused hours of headaches. I will point out some of the problems I had with this section.<br />
<br />
"userspace utilities for the management of file systems that will be used on the system" <br />
is wordy and vague. It is unhelpful to someone completely new. The hyperlink points to types of file systems which is not intuitive to the statements suggestion. At the very least, "userspace utilities" should be hyperlinked to a section of programs the statement is suggesting. Several months on, I still am unsure of what they are eluding to.<br />
<br />
"specific firmware for other devices not included in linux-firmware (e.g. sof-firmware for sound cards)"<br />
An absolute beginner does not know what specific firmware are not included in linux-firmware. The suggestion of sound cards is extremely outdated, and frankly makes it seem like linux-firmware is going to leave you needing a lot of drivers if it cannot even operate your sound card out of the box. This confusion led me down a rabbit hole of installing(or trying to find) CPU microcode updates, nvidia drivers, wired or wireless drivers, motherboard drivers, and so on.<br />
<br />
"software necessary for networking (e.g. a network manager or a standalone DHCP client, authentication software for Wi-Fi, ModemManager for mobile broadband connections)" My first problem was I was unaware of the need to systemctl enable the networking software, which led me to installing multiple DHCP clients and causing issues further down the road. I am now aware that if I had read more into the software. I believe a simple reminder to systemctl enable the networking software could save a lot of people problems. <br />
<br />
"a text editor,"<br />
The hyperlink just throws a list of 70 or so text editors at you. This is quite needlessly daunting to someone new. Even something as basic as "e.g. vim" would have spared me from being so overwhelmed this far into my troubles with this section. <br />
<br />
"packages for accessing documentation in man and info pages: man-db, man-pages and texinfo."<br />
This should take priority above all by being placed first in this list. <br />
<br />
I would recommend a section "2.2.1 Example(s) of essential packages" be created that shows at least one example of a typical users desktop computer, and what they would install on this step.<br />
<br />
{{Unsigned|21:12, 12 June 2023 (UTC)|Todd the king}}<br />
<br />
:I would refer you to https://wiki.archlinux.org/title/Arch_Linux#User_centrality. Arch's target audience isn't absolute beginners, it's experienced Linux users that know what they want and how they want their system set up. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 22:37, 12 June 2023 (UTC)<br />
<br />
::It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems. {{Unsigned|21:12, 12 June 2023 (UTC)|Todd the king}}<br />
<br />
:::And your argument is that you don't want to read the documentation. Arch dosen't make these decisions for you, you need to either know what you want or be willing to figure out what you want. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 22:49, 12 June 2023 (UTC)<br />
<br />
::::I did read the documentation, and I did figure out what I wanted. It took much longer than it should have because the instructions were hazy on this section. Why give any examples of software or suggestions of configuration to use in the article at all if this is the mindset of the guide? Where is the line and why? [[User:Todd the king|Todd the king]] ([[User talk:Todd the king|talk]]) 23:09, 12 June 2023 (UTC)<br />
<br />
:First of all, welcome :)<br />
:Now, I'm sorry but: <br />
<br />
::"userspace utilities for the management of file systems that will be used on the system" <br />
::is wordy and vague. It is unhelpful to someone completely new. The hyperlink points to types of file systems which is not intuitive to the statements suggestion. At the very least, "userspace utilities" should be hyperlinked to a section of programs the statement is suggesting. Several months on, I still am unsure of what they are eluding to.<br />
<br />
:The very first section of the linked page (i.e. [[File systems#Types of file systems]] has a table which helpfully has a "Userspace utilities" column, I fail to see how skipping the page introduction would make this more obvious. <br />
<br />
::"specific firmware for other devices not included in linux-firmware (e.g. sof-firmware for sound cards)"<br />
::An absolute beginner does not know what specific firmware are not included in linux-firmware. The suggestion of sound cards is extremely outdated, and frankly makes it seem like linux-firmware is going to leave you needing a lot of drivers if it cannot even operate your sound card out of the box. This confusion led me down a rabbit hole of installing(or trying to find) CPU microcode updates, nvidia drivers, wired or wireless drivers, motherboard drivers, and so on.<br />
<br />
:An absolute beginner's encouraged to seek help if he's unsure of what advice is applicable to its hardware. As shown in the tables in [[Laptop/Lenovo]], various recent laptops ''do'' require [[ALSA firmware]], while some models require specific drivers (and its respective firmware) for wireless networking: [[Broadcom wireless]], or even some USB3 chipsets on the motherboard with {{AUR|upd72020x-fw}} for example. <br />
<br />
::"software necessary for networking (e.g. a network manager or a standalone DHCP client, authentication software for Wi-Fi, ModemManager for mobile broadband connections)" My first problem was I was unaware of the need to systemctl enable the networking software, which led me to installing multiple DHCP clients and causing issues further down the road. I am now aware that if I had read more into the software. I believe a simple reminder to systemctl enable the networking software could save a lot of people problems. <br />
<br />
: Someone manually configuring a [[Network configuration#Static IP address|static ip connection]] would not need that step, while every dedicated [[network manager]] page explains the need for enabling their respective systemd unit. <br />
<br />
::"a text editor,"<br />
::The hyperlink just throws a list of 70 or so text editors at you. This is quite needlessly daunting to someone new. Even something as basic as "e.g. vim" would have spared me from being so overwhelmed this far into my troubles with this section. <br />
<br />
:Not picking a default text editor is a feature and not a bug: every choice made of a "sane default" would create endless bikeshedding (see [[Wikipedia:Editor war]]), although a popular beginner friendly one has been used as an example in [[Help:Reading#Append, add, create, edit]]. <br />
<br />
::"packages for accessing documentation in man and info pages: man-db, man-pages and texinfo."<br />
::This should take priority above all by being placed first in this list. <br />
<br />
:Man pages can be accessed with man.archlinux.org instead of wasting bandwidth and disk space by installing and updating a local version. <br />
<br />
::I would recommend a section "2.2.1 Example(s) of essential packages" be created that shows at least one example of a typical users desktop computer, and what they would install on this step.<br />
<br />
: This guide is not specific to desktop users, a dedicated section is out of scope. <br />
<br />
: As a general answer, our aim is to provide readers with the information they need to make an educated decision at every step, not rubber stamping the [https://pkgstats.archlinux.de/ popularity] of various software solutions. <br />
: While a little overwhelming at first, this approach has proven itself to be the best working on the long term: [[Help:Reading#Organization]]. <br />
: --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 00:07, 13 June 2023 (UTC)<br />
<br />
:I replaced "sound cards" with "onboard audio" which will hopefully get the message across better. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:56, 13 June 2023 (UTC)<br />
<br />
:After a bit of staring at [[Installation guide#Install essential packages]], I can confidentially say I can find some fault in each and any bullet point. So, starting from the top, I propose changing the first one to:<br />
::[[File systems|userspace utilities for file systems]] that will be used on the system—for the purposes of e.g. file system creation and [[fsck]],<br />
: It gets rid of the vague "for the management" and adds actual reasons for wanting the userspace utilities.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:37, 13 June 2023 (UTC)<br />
<br />
::Since no one objected, and I finally remembered this discussion, I updated the page per my suggestion above. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:06, 22 June 2023 (UTC)<br />
<br />
:"utilities for accessing [[RAID]] or [[LVM]] partitions" could be replaced with something like:<br />
::utilities for accessing and managing [[RAID#Installation|RAID]] or [[LVM#Installation|LVM]] if they will be used on the system,<br />
:These things can actually be ''managed'', and they are not limited to ''partitions''. Also IMO it's better to directly link to the section that lists the packages to install.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:48, 22 June 2023 (UTC)<br />
<br />
::[[Special:Diff/782222|Done]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:23, 30 June 2023 (UTC)<br />
<br />
:On to the next one:<br />
::specific firmware for other devices not included in {{Pkg|linux-firmware}} (e.g. {{Pkg|sof-firmware}} for [[Advanced Linux Sound Architecture#ALSA firmware|onboard audio]], {{Pkg|linux-firmware-marvell}} for Marvell wireless and any of the multiple firmware packages for [[Broadcom wireless]]),<br />
:It lists the only split-package of {{Pkg|linux-firmware}} that I've heard anyone actually need and also the dreaded Broadcom wireless.<br />
: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:23, 30 June 2023 (UTC)<br />
<br />
::Since no one has stopped me yet: [[Special:Diff/782857]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:20, 9 July 2023 (UTC)<br />
<br />
:I do not think the "software necessary for networking" bullet point lacks anything. Instead, [[Installation guide#Network configuration]] could be improved to avoid giving the impression that ''installing'' a piece of software is enough to make it operational. Unfortunately I can't think of a good, easily digestible phrase that accomplishes that. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:27, 9 July 2023 (UTC)<br />
<br />
::Best I can come up for [[Installation guide#Network configuration]] is:<br />
:::That may include installing suitable [[network management]] software, configuring it if necessary and enabling its systemd unit so that it starts at boot.<br />
::Thoughts?<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:04, 15 August 2023 (UTC)<br />
<br />
:::I would slightly alter the order of the words: <br />
::::That may include installing suitable [[network management]] software, configuring it and enabling its systemd unit so that it starts at boot if necessary.<br />
:::Outside of that minor nitpick, it is probably beneficial to be explicitly pointing out commons steps instead of hoping people will read the Wiki page of every software they install :P --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 10:38, 15 August 2023 (UTC)<br />
<br />
::::The thought was that you need to install the package and enable the unit, but configuring is not always required. E.g. NetworkManager & dhcpcd can be simply be used as is for Ethernet connections with no prior configuration. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:42, 15 August 2023 (UTC)<br />
<br />
:::::👍 --[[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 11:02, 15 August 2023 (UTC)<br />
<br />
::::::[[Special:Diff/786476|Done]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:04, 30 August 2023 (UTC)<br />
:I think it would be better if "a [[text editor]]" would instead say "a console [[text editor]]", since you won't be able to use graphical ones in the tty. The issue with that text is that [[List of applications#Vi-style text editors]] and [[List of applications#Emacs-style text editors]] are separate sections on the same level as "console" and "graphical". -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 11:35, 23 October 2023 (UTC)<br />
::And linking to [[List of applications#Console 23]] would skip the vi/emacs-style editors so it's not an option either :/ -- [[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 11:41, 23 October 2023 (UTC)<br />
<br />
== Default mount permissions for ESP are insecure for systemd-boot ==<br />
<br />
I suggest editing the `Mount_the_file_systems` section and adding explicit permissions to the mount that will remove world readability from the ESP.<br />
<br />
The removed file and directory masks seem to be `fmask=0022,dmask=0022`, what should instead be suggested is to at least remove world with `fmask=0027,dmask=0027`.<br />
<br />
When using a bootloader like systemd-boot, which puts secrets `ESP/loader/random-seed`, it will complain that the mountpoint and the file itself have world-readable permissions, see https://t.me/archlinuxgroup/690016 for screenshot.<br />
<br />
Per-file permissions are impossible as the only supported file system by default as per UEFI spec is FAT.<br />
<br />
This should ALSO be mentioned in the [[Systemd-boot]] page.<br />
<br />
Perhaps just add it there and make a note in the installation guide "if using systemd-boot as a bootloader..."? I am not sure if this is a problem with other bootloaders.<br />
<br />
<br />
[[User:C0rn3j|C0rn3j]] ([[User talk:C0rn3j|talk]]) 19:17, 15 October 2023 (UTC)<br />
<br />
:There's an existing discussion about the topic in [[Talk:EFI system partition#Mountpoint umask]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:42, 16 October 2023 (UTC)<br />
<br />
== <s>change ping archlinux.org to ping -c 3 archlinux.org</s> ==<br />
<br />
that way it stops pinging [[User:Matthewq337|Matthewq337]] ([[User talk:Matthewq337|talk]]) 19:41, 13 November 2023 (UTC)<br />
<br />
:The [[ping]] link already leads to instructions how to stop it. See also [[Special:Diff/731818#Ping endless]] [[User:Andreymal|andreymal]] ([[User talk:Andreymal|talk]]) 19:51, 13 November 2023 (UTC)<br />
<br />
== <s>localectl list-keymaps works</s> ==<br />
<br />
[[#Read this first before adding new suggestions]] says "{{ic|localectl list-keymaps}} does not work due to bug {{Bug|46725}}".<br />
<br />
I won't pretend to understand [https://github.com/torvalds/linux/blob/master/fs/overlayfs/inode.c fs/overlayfs/inode.c], but from what I can guess, while [https://lore.kernel.org/all/1479133374-9292-1-git-send-email-quorum.laval@gmail.com/ the patch] was never merged, some other changes over the years resulted in it having the same effect.<br />
<br />
I propose using {{ic|localectl list-keymaps}} in [[Installation guide#Set the console keyboard layout and font]].<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:20, 15 November 2023 (UTC)<br />
<br />
:👍 Since it works now :)<br />
:-- [[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 10:00, 15 November 2023 (UTC)<br />
<br />
:👍 Since it works now :) — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:32, 21 November 2023 (UTC)<br />
<br />
::[[Special:Diff/793695|Implemented]]. "pass its name" was probably not the prettiest way to word it, but it'll do for now. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:38, 1 December 2023 (UTC)<br />
<br />
:::Please update the notes in [[#Read this first before adding new suggestions]] as well. I don't know if the warning still applies to other *ctl tools. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:07, 2 December 2023 (UTC)<br />
<br />
== <s>Use localectl set-keymap</s> ==<br />
<br />
Instead of using {{ic|loadkeys}} in [[Installation guide#Set the console keyboard layout and font]] and manually editing {{ic|/etc/vconsole.conf}} in [[Installation guide#Localization]], I propose instructing to use {{ic|localectl set-keymap}}.<br />
<br />
Unlike ''loadkeys'', ''localectl'' writes to {{ic|/etc/vconsole.conf}} so it's persistent. It also writes {{ic|XKBLAYOUT}}, {{ic|XKBMODEL}}, {{ic|XKBVARIANT}} and {{ic|XKBOPTIONS}} which maybe will be used by something in the future.<br />
<br />
-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:53, 1 December 2023 (UTC)<br />
<br />
:What is the value of "persistent" in this case? The file {{ic|/etc/vconsole.conf}} only applies to the live system. There is {{ic|--machine}} but it only works with [[systemd-nspawn]] containers. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 17:59, 2 December 2023 (UTC)<br />
::Yeah, there's no value for it in the live system. And since you need to configure {{ic|FONT{{=}}}} manually anyway (which [[Installation guide#Localization]] doesn't even mention), there's probably no reason to change things for now. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:13, 3 December 2023 (UTC)<br />
<br />
== <s>Mention POSIX compatibility in list of packages for consideration to installation</s> ==<br />
<br />
Please mention {{Pkg|posix-user-portability}} in the list of packages for user's consideration of installation<br />
<br />
-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 16:41, 2 December 2023 (UTC)<br />
<br />
:Why? I have never installed this package and have not experienced any problems, which means that this package is clearly not essential. — [[User:Andreymal|andreymal]] ([[User talk:Andreymal|talk]]) 17:21, 2 December 2023 (UTC)<br />
::I mean, I never installed e.g. utilities for accessing and managing RAID or LVM, yet they are on the list. <br />
::Man pages also aren't essential, yet are listed. Software for networking also technically isn't essential. <br />
::Since this is list of packages to consider, I think it would be nice to know upfront about something potentially missing instead of when a script breaks due to lacking utility.<br />
::-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 17:46, 2 December 2023 (UTC)<br />
:👎 from me, we don't advertise being POSIX-compatible by default, nor is this a common issue I've seen users being bitten by. <br />
:-- [[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 17:35, 2 December 2023 (UTC)<br />
::Of course, that why I'm not asking to include it in {{Pkg|base}} package, but putting it here so users are explicitly aware during installation some standard utilities may be missing.<br />
::-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 17:48, 2 December 2023 (UTC)<br />
<br />
::Having this package installed is not a common expectation, as demonstrated by its recent addition in 2020. The base package (and base group before that) has been around for over a decade. Closing -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 18:06, 2 December 2023 (UTC)<br />
:::Could we have at least an explicit warning about it somewhere?<br />
:::Most popular utilities are already pulled as dependencies for other packages, so users don't notice.<br />
:::But they may sooner or later want to use a script from outside repos, which needs a (standard) utility not installed as dependency for something else.<br />
:::-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 20:38, 2 December 2023 (UTC)<br />
::::Then they can just install packages they need. I don't see any need to add a warning. — [[User:Andreymal|andreymal]] ([[User talk:Andreymal|talk]]) 20:50, 2 December 2023 (UTC)<br />
:::::Because, for better or worse, users of *nix systems usually expect those utilities being present by default.<br />
:::::It's really not nice when your POSIX compliant script suddenly breaks due to missing utility (and borks files).<br />
:::::<small><sup>(Yes, I'm speaking from experience; no, I don't remember which utility it was - I had this suggestion on my TODO list for over half a year; yes, technically I could've deduced that from the bullet about text editor, but it's not so obvious)</sup></small><br />
:::::-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 21:35, 2 December 2023 (UTC)<br />
:::::: Are you seriously arguing that everyone should be installing telnet, s-nail, ed, pax, etc? No. Just no. Even cronie is silly on a systemd system. [[User:Scimmia|Scimmia]] ([[User talk:Scimmia|talk]]) 04:50, 3 December 2023 (UTC)<br />
:::::::I really don't know how did you reach such a conclusion. Of course I don't argue for that.<br />
:::::::On this page is step [[Installation guide#Install_essential_packages|2.2 Install essential packages]], where there are words "In particular, consider installing:" after which is a list of packages a user might want to install.<br />
:::::::Second point from that list ("utilities for accessing and managing RAID or LVM if they will be used on the system") clearly shows, those aren't mandatory packages.<br />
:::::::Thus this list is a perfect place to inform user that {{Pkg|base}} package doesn't contain standard POSIX utilities and they need to install them extra if they desire.<br />
:::::::-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 05:24, 3 December 2023 (UTC)<br />
::::::::Read you quoted sentence until the end: "if they will be used on the system": they are present on the live media and will not be automatically installed after setting up the RAID, preventing boot and thus qualifying as "essential".<br />
::::::::The common advice for users when wanting to install a package from outside the repositories is to create a PKGBUILD for it, which should allow catching missing dependencies at that point. <br />
::::::::I'd be really interested in which tool was missing for you, as {{Pkg|posix-user-portability}} is simply a meta-package depending on {{Pkg|cronie}}, {{Pkg|inetutils}}, {{Pkg|posix}}, {{Pkg|util-linux}} and {{Pkg|vi}}, it feels excessive to point people to install a whole array of packages if they're only missing a single one. <br />
::::::::Maybe this could be a new subsection in [[General recommendations#Console improvements]], to explicitly explain we are only ''mostly'' POSIX compatible by default, and people who require it can install the meta-package to fit that need? <br />
::::::::-- [[User:Erus Iluvatar|Erus Iluvatar]] ([[User talk:Erus Iluvatar|talk]]) 08:24, 3 December 2023 (UTC)<br />
:::::::::It wasn't being installed as external package, just regular user shell script; simple <code>chmod +x script && ./script</code>. The only expectation were standard POSIX utilities.<br />
:::::::::I'm pretty sure the missing one was something very basic, like {{Pkg|bc}} or {{Pkg|ex}}.<br />
:::::::::Installing whole array of packages may feel excessive for one script, but if you have multiple of them, then the whole point of the standard is to have this bare minimum not to worry about.<br />
:::::::::So well, I guess putting it in [[General recommendations]] may also be a good place. Always better than learning that when something breaks.<br />
:::::::::-- [[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 10:29, 3 December 2023 (UTC)<br />
<br />
== Mention that partitionning is more-or-less permanent ==<br />
<br />
While there are solutions to reformat/repartition drives after the fact, it should be made obvious (warning/info box?) that changing partitions after a system is installed can be a major PITA. I've seen too many reddit support posts about wanting to add more space to the root partition or encrypting everything after the fact.<br />
<br />
Therefore, I suggest adding in [[Installation guide#Partition the disks|section 1.9]]:<br />
<br />
{{Warning|Re-partitioning disks after the fact is difficult and involves moving data and system around. It is therefore recommended to properly size and format disks, according to: [[Partitioning]]. If you need disk encryption, now is the time to look into [[Data-at-rest_encryption]].}} [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 18:05, 5 December 2023 (UTC)</div>Moviurohttps://wiki.archlinux.org/index.php?title=Systemd-networkd&diff=779352Systemd-networkd2023-05-22T07:17:02Z<p>Moviuro: /* Bonding a wired and wireless interface */ Info: use PermanentMACAddress, not MACAddress</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Network managers]]<br />
[[Category:Virtualization]]<br />
[[de:Systemd/systemd-networkd]]<br />
[[es:Systemd-networkd]]<br />
[[fr:Systemd-networkd]]<br />
[[ja:systemd-networkd]]<br />
[[ru:Systemd-networkd]]<br />
[[zh-hans:Systemd-networkd]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|systemd-resolved}}<br />
{{Related|systemd-nspawn}}<br />
{{Related|Network bridge}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related|:Category:Network configuration}}<br />
{{Related articles end}}<br />
<br />
''systemd-networkd'' is a system daemon that manages network configurations. It detects and configures network devices as they appear; it can also create virtual network devices. This service can be especially useful to set up complex network configurations for a container managed by [[systemd-nspawn]] or for virtual machines. It also works fine on simple connections.<br />
<br />
== Basic usage ==<br />
<br />
The {{Pkg|systemd}} package is part of the default Arch installation and contains all needed files to operate a wired network. Wireless adapters, covered later in this article, can be set up by services, such as [[wpa_supplicant]] or [[iwd]].<br />
<br />
=== Required services and setup ===<br />
<br />
To use ''systemd-networkd'', [[start/enable]] {{ic|systemd-networkd.service}}.<br />
<br />
{{Note|You must ensure that no other service that wants to configure the network is running; in fact, multiple networking services will conflict. You can find a list of the currently running services with {{ic|1=systemctl --type=service}} and then [[stop]] them.}}<br />
<br />
It is optional to also configure [[systemd-resolved]], which is a network name resolution service to local applications, considering the following points:<br />
<br />
* It is important to understand how [[resolv.conf]] and ''systemd-resolved'' interact to properly configure the DNS that will be used, some explanations are provided in [[systemd-resolved]].<br />
* ''systemd-resolved'' is required if DNS entries are specified in ''.network'' files.<br />
* ''systemd-resolved'' is also required if you want to obtain DNS addresses from DHCP servers or IPv6 router advertisements.<br>(by setting ({{ic|1=DHCP=}} and/or {{ic|1=IPv6AcceptRA=}} in the {{ic|[Network]}} section, and {{ic|1=UseDNS=yes}} (the default) in the corresponding section(s) {{ic|[DHCPv4]}}, {{ic|[DHCPv6]}}, {{ic|[IPv6AcceptRA]}}, see {{man|5|systemd.network}}).<br />
* Note that ''systemd-resolved'' can also be used without ''systemd-networkd''.<br />
<br />
=== systemd-networkd-wait-online ===<br />
<br />
Enabling {{ic|systemd-networkd.service}} also enables {{ic|systemd-networkd-wait-online.service}}, which is a oneshot system service that waits for the network to be configured. The latter has {{ic|1=WantedBy=network-online.target}}, so it will be started only when {{ic|network-online.target}} itself is enabled or pulled in by some other unit. See also [[systemd#Running services after the network is up]].<br />
<br />
By default, {{ic|systemd-networkd-wait-online.service}} waits for all links managed by ''systemd-networkd'' to be fully configured or failed, and for at least one link to be online.<br />
<br />
If your system has multiple network interfaces, but some are not expected to be connected all the time (e.g. if you have a dual-port Ethernet card, but only one cable plugged in), starting {{ic|systemd-networkd-wait-online.service}} will fail after the default timeout of 2 minutes. This may cause an unwanted delay in the startup process. To change the behaviour to wait for ''any'' interface rather than ''all'' interfaces to become online, [[edit]] the service and add the {{ic|--any}} parameter to the {{ic|ExecStart}} line:<br />
<br />
{{hc|/etc/systemd/system/systemd-networkd-wait-online.service.d/wait-for-only-one-interface.conf|2=<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --any<br />
}}<br />
<br />
Alternatively, use {{ic|systemd-networkd-wait-online@.service}} to wait for a specific interface . E.g. to wait for {{ic|enp1s0}}, [[disable]] {{ic|systemd-networkd-wait-online.service}} and [[enable]] {{ic|systemd-networkd-wait-online@enp1s0.service}}.<br />
<br />
See {{man|8|systemd-networkd-wait-online}} for more details.<br />
<br />
=== Configuration examples ===<br />
<br />
All configurations in this section are stored as {{ic|foo.network}} in {{ic|/etc/systemd/network/}}. For a full listing of options and processing order, see [[#Configuration files]] and {{man|5|systemd.network}}.<br />
<br />
systemd/udev automatically assigns predictable, stable network interface names for all local Ethernet, WLAN, and WWAN interfaces. Use {{ic|networkctl list}} to list the devices on the system.<br />
<br />
After making changes to a configuration file, [[restart]] {{ic|systemd-networkd.service}}.<br />
<br />
{{Note|<br />
* The options specified in the configuration files are case sensitive.<br />
* In the examples below, {{ic|enp1s0}} is the wired adapter and {{ic|wlp2s0}} is the wireless adapter. These names can be different on different systems. See [[Network configuration#Network interfaces]] for checking your adapter names.<br />
* It is also possible to use a wildcard, e.g. {{ic|1=Name=en*}} or {{ic|1=Name=wl*}}.<br />
* Devices can also be matched by their type. E.g. {{ic|1=Type=ether}} for Ethernet, {{ic|1=Type=wlan}} for Wi-Fi and {{ic|1=Type=wwan}} for WWAN. Note that {{ic|1=Type=ether}} will also match virtual Ethernet interfaces ({{ic|veth*}}), which may be undesirable.<br />
* If you want to disable IPv6, see [[IPv6#systemd-networkd_3|IPv6#systemd-networkd]].<br />
}}<br />
<br />
==== Wired adapter using DHCP ====<br />
<br />
{{hc|/etc/systemd/network/20-wired.network|2=<br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
DHCP=yes<br />
}}<br />
<br />
==== Wired adapter using a static IP ====<br />
<br />
{{hc|/etc/systemd/network/20-wired.network|2=<br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
Address=10.1.10.9/24<br />
Gateway=10.1.10.1<br />
DNS=10.1.10.1<br />
}}<br />
<br />
{{ic|1=Address=}} can be used more than once to configure multiple IPv4 or IPv6 addresses. See [[#network files]] or {{man|5|systemd.network}} for more options.<br />
<br />
==== Wireless adapter ====<br />
<br />
In order to connect to a wireless network with ''systemd-networkd'', a wireless adapter configured with another application such as [[wpa_supplicant]] or [[iwd]] is required.<br />
<br />
{{hc|/etc/systemd/network/25-wireless.network|2=<br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=yes<br />
IgnoreCarrierLoss=3s<br />
}}<br />
<br />
If the wireless adapter has a static IP address, the configuration is the same (except for the interface name) as in a [[#Wired adapter using a static IP|wired adapter]].<br />
<br />
{{Tip|{{ic|1=IgnoreCarrierLoss=3s}} ensures that ''systemd-networkd'' will not re-configure the interface (e.g., release and re-acquire a DHCP lease) for a short period (3 seconds in this example) while the wireless interface roams to another access point within the same wireless network (SSID), which translates to shorter downtime when roaming.}}<br />
<br />
To authenticate to the wireless network, use e.g. [[wpa_supplicant]] or [[iwd]].<br />
<br />
==== Wired and wireless adapters on the same machine ====<br />
<br />
This setup will enable a DHCP IP for both a wired and wireless connection making use of the metric directive to allow the kernel to decide on-the-fly which one to use. This way, no connection downtime is observed when the wired connection is unplugged.<br />
<br />
The kernel's route metric (same as configured with ''ip'') decides which route to use for outgoing packets, in cases when several match. This will be the case when both wireless and wired devices on the system have active connections. To break the tie, the kernel uses the metric. If one of the connections is terminated, the other automatically wins without there being a gap with nothing configured (ongoing transfers may still not deal with this nicely but that is at a different OSI layer).<br />
<br />
''systemd-networkd'' [https://github.com/systemd/systemd/issues/17698 does not set per-interface-type default route metrics], so it needs to be configured manually:<br />
<br />
{{Note|The {{ic|Metric}} option is for static routes while the {{ic|RouteMetric}} option is for setups not using static routes. See {{man|5|systemd.network}} for more details.}}<br />
<br />
{{hc|/etc/systemd/network/20-wired.network|2=<br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
DHCP=yes<br />
<br />
[DHCPv4]<br />
RouteMetric=10<br />
<br />
[IPv6AcceptRA]<br />
RouteMetric=10<br />
}}<br />
<br />
{{hc|/etc/systemd/network/25-wireless.network|2=<br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=yes<br />
<br />
[DHCPv4]<br />
RouteMetric=20<br />
<br />
[IPv6AcceptRA]<br />
RouteMetric=20<br />
}}<br />
<br />
==== Renaming an interface ====<br />
<br />
Instead of [[Network configuration#Change interface name|editing udev rules]], a ''.link'' file can be used to rename an interface. A useful example is to set a predictable interface name for a USB-to-Ethernet adapter based on its MAC address, as those adapters are usually given different names depending on which USB port they are plugged into.<br />
<br />
{{hc|head=/etc/systemd/network/10-ethusb0.link|output=<br />
[Match]<br />
MACAddress=12:34:56:78:90:ab<br />
<br />
[Link]<br />
Description=USB to Ethernet Adapter<br />
Name=ethusb0<br />
}}<br />
<br />
{{Note|Any user-supplied ''.link'' '''must''' have a lexically earlier file name than the default config {{ic|99-default.link}} in order to be considered at all. For example, name the file {{ic|10-ethusb0.link}} and not {{ic|ethusb0.link}}.}}<br />
<br />
== Configuration files ==<br />
<br />
The global configuration file in {{ic|/etc/systemd/networkd.conf}} may be used to override some defaults only. The main configuration is performed per network device. Configuration files are located in {{ic|/usr/lib/systemd/network/}}, the volatile runtime network directory {{ic|/run/systemd/network/}} and the local administration network directory {{ic|/etc/systemd/network/}}. Files in {{ic|/etc/systemd/network/}} have the highest priority.<br />
<br />
There are three types of configuration files. They all use a format similar to [[systemd#Writing unit files|systemd unit files]]. <br />
<br />
* ''.network'' files. They will apply a network configuration for a ''matching'' device<br />
* ''.netdev'' files. They will create a ''virtual network device'' for a ''matching'' environment<br />
* ''.link'' files. When a network device appears, [[udev]] will look for the first ''matching'' ''.link'' file<br />
<br />
They all follow the same rules: <br />
<br />
* If '''all''' conditions in the {{ic|[Match]}} section are matched, the profile will be activated<br />
* an empty {{ic|[Match]}} section means the profile will apply in any case (can be compared to the {{ic|*}} wildcard)<br />
* all configuration files are collectively sorted and processed in lexical order, regardless of the directory in which they live<br />
* files with identical name replace each other<br />
<br />
{{Tip|<br />
* Files in {{ic|/etc/systemd/network/}} override the corresponding system-supplied file in {{ic|/usr/lib/systemd/network/}}. You can also create a symlink to {{ic|/dev/null}} to "mask" a system file.<br />
* systemd accepts the values {{ic|1}}, {{ic|true}}, {{ic|yes}}, {{ic|on}} for a true boolean, and the values {{ic|0}}, {{ic|false}}, {{ic|no}}, {{ic|off}} for a false boolean. See {{man|7|systemd.syntax}}.<br />
* systemd-networkd will alter routing tables also for other network software. If this is undesired, configure {{ic|1=ManageForeignRoutingPolicyRules=}} in {{man|5|networkd.conf}} accordingly. For example, see [[WireGuard#Connection lost after sleep using systemd-networkd]].<br />
}}<br />
<br />
=== network files ===<br />
<br />
{{Remove|Duplicates the {{man|5|systemd.network}} man page.}}<br />
<br />
These files are aimed at setting network configuration variables, especially for servers and containers.<br />
<br />
''.network'' files have the following sections: {{ic|[Match]}}, {{ic|[Link]}}, {{ic|[Network]}}, {{ic|[Address]}}, {{ic|[Route]}}, and {{ic|[DHCPv4]}}. Below are commonly configured keys for each section. See {{man|5|systemd.network}} for more information and examples.<br />
<br />
==== [Match] ====<br />
<br />
{| class = "wikitable"<br />
! Parameter !! Description !! Accepted Values !! Default Value<br />
|-<br />
| {{ic|1=Name=}} || Match device names, e.g. {{ic|en*}}. By prefixing with {{ic|!}}, the list can be inverted. || white-space separated device names with globs, logical negation ({{ic|!}}) ||<br />
|-<br />
| {{ic|1=MACAddress=}} || Match MAC addresses, e.g. {{ic|1=MACAddress=01:23:45:67:89:ab 00-11-22-33-44-55 AABB.CCDD.EEFF}} || whitespace-separated MAC addresses in full colon-, hyphen- or dot-delimited hexadecimal || <br />
|-<br />
| {{ic|1=Host=}} || Match the hostname or machine ID of the host. || hostname string with globs, {{man|5|machine-id}} ||<br />
|-<br />
| {{ic|1=Virtualization=}} || Check whether the system is executed in a virtualized environment. {{ic|1=Virtualization=false}} will only match your host machine, while {{ic|1=Virtualization=true}} matches any container or VM. It is possible to check for a specific virtualization type or implementation, or for a user namespace (with {{ic|private-users}}). || boolean, logical negation ({{ic|!}}), type ({{ic|vm}}, {{ic|container}}), implementation (see {{man|1|systemd-detect-virt}}), {{ic|private-users}} ||<br />
|}<br />
<br />
==== [Link] ====<br />
<br />
{| class = "wikitable"<br />
! Parameter !! Description !! Accepted Values !! Default Value<br />
|-<br />
| {{ic|1=MACAddress=}} || Assign a hardware address to the device. Useful for [[MAC address spoofing#systemd-networkd|MAC address spoofing]]. || full colon-, hyphen- or dot-delimited hexadecimal MAC addresses ||<br />
|-<br />
| {{ic|1=MTUBytes=}} || Maximum transmission unit in bytes to set for the device. Note that if IPv6 is enabled on the interface, and the MTU is chosen below 1280 (the minimum MTU for IPv6) it will automatically be increased to this value. Setting a larger MTU value (e.g. when using [[jumbo frames]]) can significantly speed up your network transfers || integer (usual suffixes K, M, G, are supported and are understood to the base of 1024) ||<br />
|-<br />
| {{ic|1=Multicast=}} || allows the usage of [[wikipedia:Multicast_address|multicast]] || boolean || ? not documented ?<br />
|}<br />
<br />
==== [Network] ====<br />
<br />
{| class = "wikitable"<br />
! Parameter !! Description !! Accepted Values !! Default Value<br />
|-<br />
| {{ic|1=DHCP=}} || Controls DHCPv4 and/or DHCPv6 client support. || boolean, {{ic|ipv4}}, {{ic|ipv6}} || {{ic|false}}<br />
|-<br />
| {{ic|1=DHCPServer=}} || If enabled, a DHCPv4 server will be started. || boolean || {{ic|false}}<br />
|-<br />
| {{ic|1=MulticastDNS=}} || Enables [[RFC:6762|multicast DNS]] support. When set to {{ic|resolve}}, only resolution is enabled, but not host or service registration and announcement. || boolean, {{ic|resolve}} || {{ic|false}}<br />
|-<br />
| {{ic|1=DNSSEC=}} || Controls DNSSEC DNS validation support on the link. When set to {{ic|allow-downgrade}}, compatibility with non-DNSSEC capable networks is increased, by automatically turning off DNSSEC in this case. || boolean, {{ic|allow-downgrade}} || {{ic|false}}<br />
|-<br />
| {{ic|1=DNS=}} || Configure static [[DNS]] addresses. May be specified more than once. || {{man|3|inet_pton}} ||<br />
|-<br />
| {{ic|1=Domains=}} || A list of domains which should be resolved using the DNS servers on this link. {{man|5|systemd.network|[NETWORK] SECTION OPTIONS}} || domain name, optionally prefixed with a tilde ({{ic|~}}) ||<br />
|-<br />
| {{ic|1=IPForward=}} || If enabled, incoming packets on any network interface will be forwarded to any other interfaces according to the routing table. See [[Internet sharing#Enable packet forwarding]] for details. || boolean, {{ic|ipv4}}, {{ic|ipv6}} || {{ic|false}}<br />
|-<br />
| {{ic|1=IPMasquerade=}} || If enabled, packets forwarded from the network interface will appear as coming from the local host. Depending on the value, implies {{ic|1=IPForward=ipv4}}, {{ic|1=IPForward=ipv6}} or {{ic|1=IPForward=yes}}. || {{ic|ipv4}}, {{ic|ipv6}}, {{ic|both}}, {{ic|no}} || {{ic|no}}<br />
|-<br />
| {{ic|1=IPv6PrivacyExtensions=}} || Configures use of stateless temporary addresses that change over time (see [[RFC:4941|RFC 4941]]). When {{ic|prefer-public}}, enables the privacy extensions, but prefers public addresses over temporary addresses. When {{ic|kernel}}, the kernel's default setting will be left in place. || boolean, {{ic|prefer-public}}, {{ic|kernel}} || {{ic|false}}<br />
|}<br />
<br />
==== [Address] ====<br />
<br />
{| class = "wikitable"<br />
! Parameter !! Description !! Accepted Values !! Default Value<br />
|-<br />
| {{ic|1=Address=}} || Specify this key more than once to configure several addresses. Mandatory unless DHCP is used. If the specified address is {{ic|0.0.0.0}} (for IPv4) or {{ic|::}} (for IPv6), a new address range of the requested size is automatically allocated from a system-wide pool of unused ranges. || static IPv4 or IPv6 address and its prefix length (see {{man|3|inet_pton}}) ||<br />
|}<br />
<br />
==== [Route] ====<br />
<br />
* {{ic|1=Gateway=}} this option is '''mandatory''' unless DHCP is used<br />
* {{ic|1=Destination=}} the destination prefix of the route, possibly followed by a slash and the prefix length <br />
<br />
If {{ic|Destination}} is not present in {{ic|[Route]}} section this section is treated as a default route.<br />
<br />
{{Tip|You can put the {{ic|1=Address=}} and {{ic|1=Gateway=}} keys in the {{ic|[Network]}} section as a short-hand if {{ic|[Address]}} section contains only an {{ic|Address}} key and {{ic|[Route]}} section contains only a {{ic|Gateway}} key.}}<br />
<br />
==== [DHCPv4] ====<br />
<br />
{| class = "wikitable<br />
! Parameter !! Description !! Accepted Values !! Default Value<br />
|-<br />
| {{ic|1=UseDNS=}} || controls whether the DNS servers advertised by the DHCP server are used || boolean || {{ic|true}}<br />
|-<br />
| {{ic|1=Anonymize=}} || when true, the options sent to the DHCP server will follow the [[RFC:7844]] (Anonymity Profiles for DHCP Clients) to minimize disclosure of identifying information || boolean || {{ic|false}}<br />
|-<br />
| {{ic|1=UseDomains=}} || controls whether the domain name received from the DHCP server will be used as DNS search domain. If set to {{ic|route}}, the domain name received from the DHCP server will be used for routing DNS queries only, but not for searching. This option can sometimes fix local name resolving when using [[systemd-resolved]] || boolean, {{ic|route}} || {{ic|false}}<br />
|}<br />
<br />
==== [DHCPServer] ====<br />
<br />
This is an example of a DHCP server configuration which works well with [[hostapd]] to create a wireless hotspot. {{ic|IPMasquerade}} adds the firewall rules for [[Internet sharing#Enable NAT|NAT]] and implies {{ic|1=IPForward=ipv4}} to enable [[Internet sharing#Enable packet forwarding|packet forwarding]].<br />
<br />
{{Accuracy|{{ic|1=IPMasquerade=ipv4}} does not add the rules for the {{ic|filter}} table, they have to be added manually. See [[systemd-nspawn#Use a virtual Ethernet link]].}}<br />
<br />
{{hc|/etc/systemd/network/''wlan0''.network|<nowiki><br />
[Match]<br />
Name=wlan0<br />
<br />
[Network]<br />
Address=10.1.1.1/24<br />
DHCPServer=true<br />
IPMasquerade=ipv4<br />
<br />
[DHCPServer]<br />
PoolOffset=100<br />
PoolSize=20<br />
EmitDNS=yes<br />
DNS=9.9.9.9<br />
</nowiki>}}<br />
<br />
=== netdev files ===<br />
<br />
{{Remove|Duplicates the {{man|5|systemd.netdev}} man page.}}<br />
<br />
These files will create virtual network devices. They have two sections: {{ic|[Match]}} and {{ic|[NetDev]}}. Below are commonly configured keys for each section. See {{man|5|systemd.netdev}} for more information and examples.<br />
<br />
==== [Match] section ====<br />
<br />
* {{ic|1=Host=}} the hostname<br />
* {{ic|1=Virtualization=}} check if the system is running in a virtualized environment<br />
<br />
==== [NetDev] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=Name=}} the interface name. '''mandatory'''<br />
* {{ic|1=Kind=}} e.g. ''bridge'', ''bond'', ''vlan'', ''veth'', ''sit'', etc. '''mandatory'''<br />
<br />
=== link files ===<br />
<br />
{{Remove|Duplicates the {{man|5|systemd.link}} man page.}}<br />
<br />
These files are an alternative to custom udev rules and will be applied by [[udev]] as the device appears. They have two sections: {{ic|[Match]}} and {{ic|[Link]}}. Below are commonly configured keys for each section. See {{man|5|systemd.link}} for more information and examples.<br />
<br />
{{Tip|Use {{ic|udevadm test-builtin net_setup_link /sys/path/to/network/device}} as the root user to diagnose problems with ''.link'' files.}}<br />
<br />
==== [Match] section ====<br />
<br />
* {{ic|1=MACAddress=}} the MAC address<br />
* {{ic|1=Host=}} the host name<br />
* {{ic|1=Virtualization=}} <br />
* {{ic|1=Type=}} the device type e.g. vlan<br />
<br />
==== [Link] section ====<br />
<br />
* {{ic|1=MACAddressPolicy=}} persistent or random addresses, or<br />
* {{ic|1=MACAddress=}} a specific address<br />
* {{ic|1=NamePolicy=}} list of policies by which the interface name should be set, e.g. kernel, keep<br />
<br />
{{Note|the system {{ic|/usr/lib/systemd/network/99-default.link}} is generally sufficient for most of the basic cases.}}<br />
<br />
== Usage with containers ==<br />
<br />
''systemd-networkd'' can provide fully automatic configuration of networking for [[systemd-nspawn]] containers when it is used on the host system as well as inside the container. See [[systemd-nspawn#Networking]] for a comprehensive overview.<br />
<br />
For the examples below, <br />
* we will limit the output of the {{ic|ip a}} command to the concerned interfaces.<br />
* we assume the ''host'' is your main OS you are booting to and the ''container'' is your guest virtual machine.<br />
* all interface names and IP addresses are only examples.<br />
<br />
=== Network bridge with DHCP ===<br />
<br />
==== Bridge interface ====<br />
<br />
First, create a virtual [[bridge]] interface with a netdev unit file. We tell systemd to create a device named ''br0'' that functions as an ethernet bridge.<br />
<br />
{{hc|/etc/systemd/network/''mybridge''.netdev|2=<br />
[NetDev]<br />
Name=br0<br />
Kind=bridge}}<br />
<br />
{{Tip|''systemd-networkd'' assigns a MAC address generated based on the interface name and the machine ID to the bridge. This may cause connection issues, for example in case of routing based on MAC filtering. To circumvent such problems you may assign a MAC address to your bridge, probably the same as your physical device, adding the line {{ic|1=MACAddress=xx:xx:xx:xx:xx:xx}} in the ''NetDev'' section above.}}<br />
<br />
[[Restart]] {{ic|systemd-networkd.service}} to have systemd create the bridge.<br />
<br />
To see the newly created bridge on the host and on the container, type:<br />
<br />
{{hc|$ ip a|<br />
3: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default <br />
link/ether ae:bd:35:ea:0c:c9 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
Note that the interface ''br0'' is listed but is still DOWN at this stage.<br />
<br />
==== Bind Ethernet to bridge ====<br />
<br />
The next step is to add to the newly created bridge a network interface. Its configuration file must be loaded before those of the bridged interfaces, so its configuration file should be alphanumerically prior to those. In the example below, we add any interface that matches the name ''en*'' into the bridge ''br0''. <br />
<br />
{{hc|/etc/systemd/network/10_''bind''.network|2=<br />
[Match]<br />
Name=en*<br />
<br />
[Network]<br />
Bridge=br0<br />
}}<br />
<br />
The Ethernet interface must not have DHCP or an IP address associated as the bridge requires an interface to bind to with no IP: modify the corresponding {{ic|/etc/systemd/network/''MyEth''.network}} accordingly to remove the addressing.<br />
<br />
==== Bridge network ====<br />
<br />
Now that the bridge has been created and has been bound to an existing network interface, the IP configuration of the bridge interface must be specified. This is defined in a third ''.network'' file, the example below uses DHCP.<br />
<br />
{{hc|/etc/systemd/network/''mybridge''.network|2=<br />
[Match]<br />
Name=br0<br />
<br />
[Network]<br />
DHCP=ipv4}}<br />
<br />
==== Configure the container ====<br />
<br />
Use the {{ic|1=--network-bridge=br0}} option when starting the container. See [[systemd-nspawn#Use a network bridge]] for details.<br />
<br />
==== Result ====<br />
<br />
* on host<br />
<br />
{{hc|$ ip a|<br />
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default <br />
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.87/24 brd 192.168.1.255 scope global br0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link <br />
valid_lft forever preferred_lft forever<br />
6: vb-''MyContainer'': <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000<br />
link/ether d2:7c:97:97:37:25 brd ff:ff:ff:ff:ff:ff<br />
inet6 fe80::d07c:97ff:fe97:3725/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
* on container<br />
<br />
{{hc|$ ip a|<br />
2: host0: <BROADCAST,MULTICAST,ALLMULTI,AUTOMEDIA,NOTRAILERS,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
link/ether 5e:96:85:83:a8:5d brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.73/24 brd 192.168.1.255 scope global host0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5c96:85ff:fe83:a85d/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
==== Notice ====<br />
<br />
* we have now one IP address for {{ic|br0}} on the host, and one for {{ic|host0}} in the container<br />
* two new interfaces have appeared: {{ic|vb-''MyContainer''}} in the host and {{ic|host0}} in the container. This comes as a result of the {{ic|1=--network-bridge=br0}} option as explained in [[systemd-nspawn#Use a network bridge]] for details.<br />
* the DHCP address on {{ic|host0}} comes from the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file.<br />
* on host<br />
<br />
{{Out of date|''brctl'' is deprecated, use {{ic|bridge link}}. See [[Network bridge#With iproute2]].}}<br />
{{hc|$ brctl show|<br />
bridge name bridge id STP enabled interfaces<br />
br0 8000.14dae9b57a88 no enp7s0<br />
vb-''MyContainer''<br />
}}<br />
<br />
the above command output confirms we have a bridge with two interfaces binded to.<br />
<br />
* on host<br />
<br />
{{hc|$ ip route|<br />
default via 192.168.1.254 dev br0 <br />
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.87<br />
}}<br />
<br />
* on container<br />
<br />
{{hc|$ ip route|<br />
default via 192.168.1.254 dev host0 <br />
192.168.1.0/24 dev host0 proto kernel scope link src 192.168.1.73<br />
}}<br />
<br />
the above command outputs confirm we have activated {{ic|br0}} and {{ic|host0}} interfaces with an IP address and Gateway 192.168.1.254. The gateway address has been automatically grabbed by ''systemd-networkd''.<br />
<br />
=== Network bridge with static IP addresses ===<br />
<br />
Setting a static IP address for each device can be helpful in case of deployed web services (e.g FTP, http, SSH). Each device will keep the same MAC address across reboots if your system {{ic|/usr/lib/systemd/network/99-default.link}} file has the {{ic|1=MACAddressPolicy=persistent}} option (it has by default). Thus, you will easily route any service on your Gateway to the desired device.<br />
<br />
The following configuration needs to be done for this setup:<br />
<br />
* on host <br />
<br />
The configuration is very similar to the [[#Network bridge with DHCP]] section. First, a virtual bridge interface needs to be created and the main physical interface needs to be bound to it. This task can be accomplished with the following two files, with contents equal to those available in the DHCP section.<br />
<br />
/etc/systemd/network/''MyBridge''.netdev<br />
/etc/systemd/network/''MyEth''.network<br />
<br />
Next, you need to configure the IP and DNS of the newly created virtual bridge interface. For example:<br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.network|<nowiki><br />
[Match]<br />
Name=br0<br />
<br />
[Network]<br />
DNS=192.168.1.254<br />
Address=192.168.1.87/24<br />
Gateway=192.168.1.254<br />
</nowiki>}}<br />
<br />
* on container<br />
<br />
To get configure a static IP address on the container, we need to override the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file, which provides a DHCP configuration for the {{ic|host0}} network interface of the container. This can be done by placing the configuration into {{ic|/etc/systemd/network/80-container-host0.network}}. For example:<br />
<br />
{{hc|/etc/systemd/network/80-container-host0.network|2=<br />
[Match]<br />
Name=host0<br />
<br />
[Network]<br />
DNS=192.168.1.254<br />
Address=192.168.1.94/24<br />
Gateway=192.168.1.254<br />
}}<br />
<br />
Make sure that {{ic|systemd-networkd.service}} is [[enabled]] in the container.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Interface and desktop integration ===<br />
<br />
''systemd-networkd'' does not have a proper interactive graphical management interface. Still, some tools are available to either display or modify the current state of the network, receive notifications or interact with the wireless configuration:<br />
<br />
* ''networkctl'' provides a [[command-line shell]] interface to query or modify the network interface states. It is worth noting that in order to change only some aspects of an interface behavior, one is required to first [[Help:Reading#Append, add, create, edit|edit]] one or more configuration files in {{ic|/etc/systemd/network/}}. <br />
* When ''networkd'' is configured with [[wpa_supplicant]], both ''wpa_cli'' and ''wpa_gui'' offer the ability to associate and configure WLAN interfaces dynamically.<br />
* {{AUR|networkd-notify-git}} can generate simple notifications in response to network interface state changes (such as connection/disconnection and re-association).<br />
* The {{AUR|networkd-dispatcher}} daemon allows executing scripts in response to network interface state changes, similar to ''NetworkManager-dispatcher''.<br />
* As for the DNS resolver ''systemd-resolved'', information about current DNS servers can be visualized with {{ic|resolvectl status}}.<br />
<br />
=== Configuring static IP or DHCP based on SSID (location) ===<br />
<br />
Often there is a situation where your home wireless network uses DHCP and office wireless network uses static IP. This mixed setup can be configured as follows:<br />
<br />
{{Note|Number in the file name decides the order in which the files are processed. You can [Match] based on SSID or BSSID or both.}}<br />
<br />
{{hc|/etc/systemd/network/24-wireless-office.network|<nowiki><br />
# special configuration for office WiFi network<br />
[Match]<br />
Name=wlp2s0<br />
SSID=office_ap_name<br />
#BSSID=aa:bb:cc:dd:ee:ff<br />
<br />
[Network]<br />
Address=10.1.10.9/24<br />
Gateway=10.1.10.1<br />
DNS=10.1.10.1<br />
#DNS=8.8.8.8<br />
</nowiki>}}<br />
<br />
{{hc|/etc/systemd/network/25-wireless-dhcp.network|<nowiki><br />
# use DHCP for any other WiFi network<br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=yes<br />
</nowiki>}}<br />
<br />
=== Bonding a wired and wireless interface ===<br />
<br />
See also [[Wireless bonding]].<br />
<br />
Bonding allows connection sharing through multiple interfaces, so if e.g. the wired interface is unplugged, the wireless is still connected and the network connectivity remains up seamlessly.<br />
<br />
Create a bond interface. In this case the mode is ''active-backup'', which means packets are routed through a secondary interface if the primary interface goes down.<br />
<br />
{{hc|/etc/systemd/network/30-bond0.netdev|<nowiki><br />
[NetDev]<br />
Name=bond0<br />
Kind=bond<br />
<br />
[Bond]<br />
Mode=active-backup<br />
PrimaryReselectPolicy=always<br />
MIIMonitorSec=1s<br />
</nowiki>}}<br />
<br />
Set the wired interface as the primary:<br />
<br />
{{hc|/etc/systemd/network/30-ethernet-bond0.network|<nowiki><br />
[Match]<br />
Name=enp0s25<br />
<br />
[Network]<br />
Bond=bond0<br />
PrimarySlave=true<br />
</nowiki>}}<br />
<br />
Set the wireless as the secondary:<br />
<br />
{{hc|/etc/systemd/network/30-wifi-bond0.network|<nowiki><br />
[Match]<br />
Name=wlan0<br />
<br />
[Network]<br />
Bond=bond0<br />
</nowiki>}}<br />
<br />
{{note|When using MAC addresses in the {{ic|[Match]}} section, use of {{ic|PermanentMACAddress}} is recommended over {{ic|MACAddress}}, see [https://github.com/systemd/systemd/issues/27432 this upstream discussion].}}<br />
<br />
Configure the bond interface as you would a normal interface:<br />
<br />
{{hc|/etc/systemd/network/30-bond0.network|<nowiki><br />
[Match]<br />
Name=bond0<br />
<br />
[Network]<br />
DHCP=yes<br />
</nowiki>}}<br />
<br />
Now if the wired network is unplugged, the connection should remain through the wireless:<br />
<br />
{{hc|$ networkctl|<nowiki><br />
IDX LINK TYPE OPERATIONAL SETUP <br />
1 lo loopback carrier unmanaged <br />
2 enp0s25 ether no-carrier configured<br />
3 bond0 bond degraded-carrier configured<br />
5 wlan0 wlan enslaved configured<br />
<br />
4 links listed.<br />
</nowiki>}}<br />
<br />
=== Speeding up TCP slow-start ===<br />
<br />
On a higher bandwidth link with moderate latency (typically a home Internet connection that is above 10 Mbit/s) the default settings for the TCP Slow Start algorithm are somewhat conservative. This issue exhibits as downloads starting slowly and taking a number of seconds to speed up before they reach the connection's full bandwidth. It is particularly noticeable with a pacman upgrade, where each package downloaded starts off slowly and often finishes before it has reached the connection's full speed.<br />
<br />
These settings can be adjusted to make TCP connections start with larger window sizes than the defaults, avoiding the time it takes for them to automatically increase on each new TCP connection[https://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/]. While this will usually decrease performance on slow connections (or if the values are increased too far) due to having to retransmit a larger number of lost packets, they can substantially increase performance on connections with sufficient bandwidth.<br />
<br />
It is important to benchmark before and after changing these values to ensure it is improving network speed and not reducing it. If you are not seeing downloads begin slowly and gradually speed up, then there is no need to change these values as they are already optimal for your connection speed. When benchmarking, be sure to test against both a high speed and low speed remote server to ensure you are not speeding up access to fast machines at the expense of making access to slow servers even slower.<br />
<br />
To adjust these values, edit the ''.network'' file for the connection:<br />
<br />
{{hc|/etc/systemd/network/eth0.network|2=<br />
[Match]<br />
Name=eth0<br />
<br />
#[Network]<br />
#Gateway=... <-- Remove this if you have it, and put it in the Gateway= line below<br />
<br />
[Route]<br />
# This will apply to the gateway supplied via DHCP. If you manually specify<br />
# your gateway, put it here instead.<br />
Gateway=_dhcp4<br />
<br />
# The defaults for these values is 10. They are a multiple of the MSS (1460 bytes).<br />
InitialCongestionWindow=10<br />
InitialAdvertisedReceiveWindow=10<br />
}}<br />
<br />
The defaults of {{ic|10}} work well for connections slower than 10 Mbit/s. For a 100 Mbit/s connection, a value of {{ic|30}} works well. The manual page {{man|5|systemd.network|[ROUTE] SECTION OPTIONS}} says a value of {{ic|100}} is considered excessive.<br />
<br />
If the [[sysctl]] setting {{ic|net.ipv4.tcp_slow_start_after_idle}} is enabled then the connection will return to these initial settings after it has been idle for some time (and often a very small amount of time). If this setting is disabled then the connection will maintain a higher window if a larger one was negotiated during packet transfer. Regardless of the setting, each new TCP connection will begin with the {{ic|Initial*}} settings set above.<br />
<br />
The sysctl setting {{ic|net.ipv4.tcp_congestion_control}} is not directly related to these values, as it controls how the congestion and receive windows are adjusted while a TCP link is active, and particularly when the path between the two hosts is congested and throughput must be reduced. The above {{ic|Initial*}} values simply set the default window values selected for each new connection, before any congestion algorithm takes over and adjusts them as needed. Setting higher initial values simply shortcuts some negotiation while the congestion algorithm tries to find the optimum values (or, conversely, setting the wrong initial values adds additional negotiation time while the congestion algorithm works towards correcting them, slowing down each newly established TCP connection for a few seconds extra).<br />
<br />
== See also ==<br />
<br />
* {{man|8|systemd-networkd}}<br />
* [https://web.archive.org/web/20201111213850/https://coreos.com/blog/intro-to-systemd-networkd/ Tom Gundersen posts on Core OS blog]<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1393759#p1393759 How to set up systemd-networkd with wpa_supplicant] (WonderWoofy's walkthrough on Arch forums)</div>Moviurohttps://wiki.archlinux.org/index.php?title=SSHFS&diff=776472SSHFS2023-04-27T14:48:02Z<p>Moviuro: /* With a systemd user unit */ Overcome limitations of systemd.mount(8): present "self-healing" mount that ~never fails</p>
<hr />
<div>[[Category:FUSE]]<br />
[[Category:Secure Shell]]<br />
[[Category:Network sharing]]<br />
[[de:sshfs]]<br />
[[es:SSHFS]]<br />
[[fr:SSHFS]]<br />
[[ja:Sshfs]]<br />
[[ru:SSHFS]]<br />
[[zh-hans:SSHFS]]<br />
{{Related articles start}}<br />
{{Related|SCP and SFTP}}<br />
{{Related|SFTP chroot}}<br />
{{Related|Pure-FTPd}}<br />
{{Related|sftpman}}<br />
{{Related articles end}}<br />
<br />
[https://github.com/libfuse/sshfs SSHFS] is a [[FUSE]]-based filesystem client for mounting remote directories over a [[Secure Shell]] connection.<br />
<br />
{{Note|This project has been archived by its developers and is no longer developed. Alternatives include the mount feature of {{Pkg|rclone}}.}}<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|sshfs}} package.<br />
<br />
{{Tip|<br />
*If you often need to mount sshfs filesystems you may be interested in using an sshfs helper, such as {{AUR|qsshfs}}, [[sftpman]], {{AUR|sshmnt}} or [https://github.com/lahwaacz/Scripts/blob/master/fmount.py fmount.py].<br />
*You may want to use [[Google Authenticator]] providing additional security as in two-step authentication.<br />
*[[SSH keys]] may be used over traditional password authentication.}}<br />
<br />
=== Mounting ===<br />
<br />
In order to be able to mount a directory the SSH user needs to be able to access it. Invoke ''sshfs'' to mount a remote directory:<br />
<br />
$ sshfs ''[user@]host:[dir] mountpoint [options]''<br />
<br />
For example:<br />
<br />
$ sshfs myuser@mycomputer:/remote/path /local/path -C -p 9876<br />
<br />
Here {{ic|-p 9876}} specifies the port number and {{ic|-C}} enables compression. For more options see the [[#Options]] section.<br />
<br />
When not specified, the remote path defaults to the remote user home directory. Default user names and options can be predefined on a host-by-host basis in {{ic|~/.ssh/config}} to simplify the ''sshfs'' usage. For more information see [[OpenSSH#Client usage]].<br />
<br />
SSH will ask for the password, if needed. If you do not want to type in the password multiple times a day, see [[SSH keys]].<br />
<br />
=== Unmounting ===<br />
<br />
To unmount the remote system:<br />
<br />
$ fusermount3 -u ''mountpoint''<br />
<br />
Example:<br />
<br />
$ fusermount3 -u /local/path<br />
<br />
== Options ==<br />
<br />
''sshfs'' can automatically convert between local and remote user IDs. Use the {{ic|1=idmap=user}} option to translate the UID of the connecting user to the remote user {{ic|myuser}} (GID remains unchanged):<br />
<br />
$ sshfs ''myuser''@''mycomputer'':''/remote/path /local/path'' -o idmap=user<br />
<br />
If you need more control over UID and GID translation, look at the options {{ic|1=idmap=file}}, {{ic|uidfile}} and {{ic|gidfile}}.<br />
<br />
A complete list of options can be found in {{man|1|sshfs}}.<br />
<br />
== Chrooting ==<br />
<br />
You may want to restrict a specific user to a specific directory on the remote system. This can be done by editing {{ic|/etc/ssh/sshd_config}}:<br />
<br />
{{hc|/etc/ssh/sshd_config|<br />
.....<br />
Match User ''someuser'' <br />
ChrootDirectory ''/chroot/%u''<br />
ForceCommand internal-sftp<br />
AllowTcpForwarding no<br />
X11Forwarding no<br />
.....<br />
}}<br />
<br />
{{Note|The chroot directory '''must''' be owned by root, otherwise you will not be able to connect.}}<br />
<br />
See also [[SFTP chroot]]. For more information check the {{man|5|sshd_config}} man page for {{ic|Match}}, {{ic|ChrootDirectory}} and {{ic|ForceCommand}}.<br />
<br />
== Automounting ==<br />
<br />
Automounting can happen on boot, or on demand (when accessing the directory). For both, the setup happens in the [[fstab]].<br />
<br />
{{Note|Keep in mind that automounting is done through the root user, therefore you cannot use hosts configured in {{ic|.ssh/config}} of your normal user.<br />
<br />
To let the root user use an SSH key of a normal user, specify its full path in the {{ic|IdentityFile}} option.<br />
<br />
'''And most importantly''', use each sshfs mount at least once manually '''while root''' on the client machine so the host's signature is added to the client's {{ic|/root/.ssh/known_hosts}} file. This can also be done manually by appending one or more of the the SSH server's public host keys (the {{ic|/etc/ssh/ssh_host_*key.pub}} files) to {{ic|/root/.ssh/known_hosts}}.<br />
}}<br />
<br />
=== On demand ===<br />
<br />
{{Expansion|Is there a way to make this work with a passphrase-protected private key? E.g. it prompts for the passphrase at first access. Alternatively, clearly state that it is not possible and why.}}<br />
<br />
With systemd on-demand mounting is possible using {{ic|/etc/fstab}} entries.<br />
<br />
Example:<br />
<br />
''user''@''host'':''/remote/path /local/path'' fuse.sshfs noauto,x-systemd.automount,_netdev,users,idmap=user,IdentityFile=/home/''user''/.ssh/id_rsa,allow_other,reconnect 0 0<br />
<br />
The important mount options here are ''noauto,x-systemd.automount,_netdev''.<br />
<br />
* ''noauto'' tells it not to mount at boot<br />
* ''x-systemd.automount'' does the on-demand magic<br />
* ''_netdev'' tells it that it is a network device, not a block device (without it "No such device" errors might happen)<br />
<br />
{{Note|After editing {{ic|/etc/fstab}}, [[reload]] the systemd configuration and the required services, which can be found by running {{ic|systemctl list-unit-files --type automount}} }}<br />
<br />
=== On boot ===<br />
<br />
An example on how to use sshfs to mount a remote filesystem through {{ic|/etc/fstab}}<br />
<br />
''user''@''host'':''/remote/path /local/path'' fuse.sshfs defaults,_netdev 0 0<br />
<br />
Take for example the ''fstab'' line<br />
<br />
llib@192.168.1.200:/home/llib/FAH /media/FAH2 fuse.sshfs defaults,_netdev 0 0<br />
<br />
The above will work automatically if you are using an SSH key for the user. See [[Using SSH Keys]].<br />
<br />
If you want to use sshfs with multiple users, add the following option:<br />
<br />
user@domain.org:/home/user /media/user fuse.sshfs defaults,'''allow_other''',_netdev 0 0<br />
<br />
In order to ensure the network is available before trying to mount, it is not only important to set the {{ic|_netdev}} mount option, but also to add either {{ic|--any}} or a specific {{ic|--interface}} to the appropriate [[systemd#Running services after the network is up|wait-online service]] for your network manager.<br />
<br />
=== Secure user access ===<br />
<br />
When automounting via [[fstab]], the filesystem will generally be mounted by root. By default, this produces undesireable results if you wish access as an ordinary user and limit access to other users.<br />
<br />
An example mountpoint configuration:<br />
<br />
''user''@''host'':''/remote/path /local/path'' fuse.sshfs noauto,x-systemd.automount,_netdev,user,idmap=user,follow_symlinks,identityfile=/home/''user''/.ssh/id_rsa,allow_other,default_permissions,uid=USER_ID_N,gid=USER_GID_N 0 0<br />
<br />
Summary of the relevant options:<br />
<br />
* ''allow_other'' - Allow other users than the mounter (i.e. root) to access the share.<br />
* ''default_permissions'' - Allow kernel to check permissions, i.e. use the actual permissions on the remote filesystem. This allows prohibiting access to everybody otherwise granted by ''allow_other''.<br />
* ''uid'', ''gid'' - set reported ownership of files to given values; ''uid'' is the numeric user ID of your user, ''gid'' is the numeric group ID of your user.<br />
<br />
=== With a systemd user unit ===<br />
<br />
Previously presented methods have no way to automatically recover if the share fails after it was successfully mounted (e.g. network failure, etc.). To overcome these limitations, we can use a user systemd unit or a template unit:<br />
<br />
{{hc|~/.local/share/systemd/user/sshfs_videos.service|2=<br />
[Unit]<br />
Description=Mount ~/Videos/ with sshfs<br />
# NB: systemd.mount(8) is not a solution because the mount will stay failed if<br />
# the server dies (or is otherwise unavailable)<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Install]<br />
WantedBy=default.target<br />
<br />
[Service]<br />
Type=exec<br />
# add more options below as needed<br />
ExecStart=/usr/bin/sshfs -f 192.168.1.100:/var/data/videos %h/Videos -o _netdev<br />
ExecStop=/usr/bin/umount %I<br />
Restart=on-failure<br />
RestartSec=20<br />
}}<br />
<br />
{{hc|~/.local/share/systemd/user/sshfs@.service|2=<br />
[Unit]<br />
Description=Mount %I with sshfs<br />
# Setup: systemctl --user edit sshfs@$(systemd-escape /local/path).service<br />
# You should define SSHFS_REMOTE and SSHFS_OPTIONS, see examples below and<br />
# systemd.exec(5)<br />
# Then: systemctl --user enable --now sshfs@"$(systemd-escape /local/path)"<br />
# NB: systemd.mount(8) is not a solution because the mount will stay failed if<br />
# the server dies (or is otherwise unavailable)<br />
After=network-online.target<br />
Wants=network-online.target<br />
<br />
[Install]<br />
WantedBy=default.target<br />
<br />
[Service]<br />
Type=exec<br />
# Define the remote in an override file<br />
#Environment=SSHFS_REMOTE="user@host:/path"<br />
# Define some ssh(1) -o options e.g. so that the unit fails fast, should it fail<br />
#Environment=SSHFS_OPTIONS="-o ServerAliveCountMax=1,ServerAliveInterval=10"<br />
ExecStart=/usr/bin/sshfs -f $SSHFS_REMOTE -o _netdev $SSHFS_OPTIONS %I<br />
ExecStop=/usr/bin/umount %I<br />
Restart=on-failure<br />
RestartSec=20<br />
}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Checklist ===<br />
<br />
Read [[OpenSSH#Checklist]] first. Further issues to check are:<br />
<br />
# Is your SSH login sending additional information from server's {{ic|/etc/issue}} file e.g.? This might confuse SSHFS. You should temporarily deactivate server's {{ic|/etc/issue}} file: {{bc|$ mv /etc/issue /etc/issue.orig}}<br />
# Keep in mind that most SSH related troubleshooting articles you will find on the web are '''not''' systemd related. Often {{ic|/etc/fstab}} definitions wrongly begin with {{bc|''sshfs#''user@host:/mnt/server/directory ... fuse ...}} instead of using the syntax {{bc|user@host:/mnt/server/directory ... fuse.''sshfs'' ... ''x-systemd'', ...}}<br />
# Check that the owner of server's source directory and content is owned by the server's user. {{bc|$ chown -R ''user_s'': /mnt/servers/directory}}<br />
# The server's user ID can be different from the client's one. Obviously both user names have to be the same. You just have to care for the client's user IDs. SSHFS will translate the UID for you with the following mount options:{{bc|1=uid=''USER_C_ID'',gid=''GROUP_C_ID''}}<br />
# Check that the client's target mount point (directory) is owned by the client user. This directory should have the same user ID as defined in SSHFS's mount options.{{bc|$ chown -R ''user_c'': /mnt/client/directory}}<br />
# Check that the client's mount point (directory) is empty. By default you cannot mount SSHFS directories to non-empty directories.<br />
<br />
=== Connection reset by peer ===<br />
<br />
* If you are trying to access the remote system with a hostname, try using its IP address, as it can be a domain name resolving issue. Make sure you edit {{ic|/etc/hosts}} with the server details.<br />
* Make sure your user can log into the server (especially when using {{ic|AllowUsers}}).<br />
* Make sure {{ic|Subsystem sftp /usr/lib/ssh/sftp-server}} is enabled in {{ic|/etc/ssh/sshd_config}} on the remote system.<br />
* If you are using a non-default key name and passing it as {{ic|-i .ssh/my_key}}, this will not work. You have to use {{ic|1=-o IdentityFile=/home/''user''/.ssh/''my_key''}}, with the full path to the key.<br />
* If your {{ic|/root/.ssh/config/}} is a symlink, you will be getting this error as well. See [https://serverfault.com/questions/507748/bad-owner-or-permissions-on-root-ssh-config this serverfault topic]<br />
* Adding the option {{ic|sshfs_debug}} (as in {{ic|sshfs -o sshfs_debug ''user''@''server'' ...}}) can help in resolving the issue.<br />
* If that does not reveal anything useful, you might also try adding the option {{ic|debug}}.<br />
* If you are trying to sshfs into a router running DD-WRT or the like, there is a solution [https://www.dd-wrt.com/wiki/index.php/SFTP_with_DD-WRT here]. (Note that the {{ic|1=-osftp_server=/opt/libexec/sftp-server}} option can be used to the sshfs command instead of patching dropbear).<br />
* If you see this only on boot, it may be that systemd is attempting to mount prior to a network connection being available. Enabling the appropriate [[systemd#Running services after the network is up|wait-online service]] for your network manager fixes this.<br />
* Old Forum thread: [https://bbs.archlinux.org/viewtopic.php?id=27613 sshfs: Connection reset by peer].<br />
<br />
{{Note|When providing more than one option for sshfs, they must be comma separated. Like so: {{ic|1=sshfs -o sshfs_debug,IdentityFile=''/path/to/key'' ''user''@''server'' ...}}).}}<br />
<br />
=== Remote host has disconnected ===<br />
<br />
If you receive this message directly after attempting to use ''sshfs'':<br />
<br />
* First make sure that the '''remote''' machine has ''sftp'' installed! It will not work, if not.<br />
* Then, check that the path of the {{ic|Subsystem sftp}} in {{ic|/etc/ssh/sshd_config}} on the remote machine is valid.<br />
<br />
=== fstab mounting issues ===<br />
<br />
To get verbose debugging output, add the following to the mount options:<br />
<br />
ssh_command=ssh\040-vv,sshfs_debug,debug<br />
{{Note|Here, {{ic|\040}} represents a space which fstab uses to separate fields.}}<br />
<br />
To be able to run {{ic|mount -av}} and see the debug output, remove the following:<br />
noauto,x-systemd.automount<br />
<br />
=== Some directories are empty ===<br />
<br />
sshfs by default does not support symlinks. If those directories happened to be symlinks, use:<br />
$ sshfs ''user''@''host'':''/remote/path /local/path'' -o follow_symlinks<br />
<br />
=== Files not refreshed ===<br />
<br />
If you see old content on remote, consider using option {{ic|1=dir_cache=no}}:<br />
$ sshfs ''user''@''host'':''/remote/path /local/path'' -o dir_cache=no<br />
<br />
=== Limited transfer on fast network ===<br />
<br />
If you observe transfer than is lower than your network capabilities and high CPU usage on the party where files are copied from, disable compression (remove {{ic|-C}} option or set {{ic|1=-o compression=no}}).<br />
<br />
== See also ==<br />
<br />
* [https://wiki.gilug.org/index.php/How_to_mount_SFTP_accesses How to mount chrooted SSH filesystem], with special care with owners and permissions questions.</div>Moviurohttps://wiki.archlinux.org/index.php?title=Bspwm&diff=774008Bspwm2023-03-27T17:57:51Z<p>Moviuro: /* Installation */ Add note regarding the lack of releases since 0.9.10 in August 2020</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Tiling window managers]]<br />
[[es:Bspwm]]<br />
[[ja:Bspwm]]<br />
[[pt:Bspwm]]<br />
[[ru:Bspwm]]<br />
[[zh-hans:Bspwm]]<br />
{{Related articles start}}<br />
{{Related|Window manager}}<br />
{{Related|Comparison of tiling window managers}}<br />
{{Related articles end}}<br />
<br />
[https://github.com/baskerville/bspwm bspwm] is a tiling window manager that represents windows as the leaves of a full binary tree. bspwm supports multiple monitors and is configured and controlled through messages. [https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html EWMH] is partially supported.<br />
<br />
== Installation ==<br />
<br />
Install {{Pkg|bspwm}} for the window manager itself (or {{AUR|bspwm-git}} for development version) and {{Pkg|sxhkd}} for the X hotkey daemon (or {{AUR|sxhkd-git}} for development version).<br />
<br />
{{Note|There have been no releases since 2020-08: if you encounter any issues or want missing features, choose the git packages.}}<br />
<br />
== Starting ==<br />
<br />
Run {{ic|bspwm}} using [[xinit]].<br />
<br />
== Configuration ==<br />
<br />
The example configuration is located in {{ic|/usr/share/doc/bspwm/examples/}}.<br />
<br />
Copy/install {{ic|bspwmrc}} from there into {{ic|~/.config/bspwm/}} and {{ic|sxhkdrc}} into {{ic|~/.config/sxhkd/}}.<br />
<br />
The file {{ic|bspwmrc}} needs to be executable since the default example is simply a shell script that in turn<br />
configures bspwm via the {{ic|bspc}} command.<br />
<br />
$ install -Dm755 /usr/share/doc/bspwm/examples/bspwmrc ~/.config/bspwm/bspwmrc<br />
$ install -Dm644 /usr/share/doc/bspwm/examples/sxhkdrc ~/.config/sxhkd/sxhkdrc<br />
<br />
These two files are where you will be setting wm settings and keybindings, respectively.<br />
<br />
See the {{man|1|bspwm}} and {{man|1|sxhkd}} manuals for detailed documentation.<br />
<br />
=== Note for multi-monitor setups ===<br />
<br />
The example bspwmrc configures ten desktops on one monitor like this:<br />
<br />
bspc monitor -d I II III IV V VI VII VIII IX X<br />
<br />
You will need to change this line and add one for each monitor, similar to this:<br />
<br />
bspc monitor DVI-I-1 -d I II III IV<br />
bspc monitor DVI-I-2 -d V VI VII<br />
bspc monitor DP-1 -d VIII IX X<br />
<br />
You can use {{ic|xrandr -q}} or {{ic|bspc query -M --names}} to find the monitor names.<br />
<br />
The total number of desktops were maintained at ten in the above example. This is so that each desktop can still be addressed with {{ic|super + {1-9,0&#125;}} in the sxhkdrc.<br />
<br />
If you want to automate your monitor-screens setup in case you change periodically monitor layouts, you need to use a conditional structure to check if a specific monitor is connected and configure it appropriately; you can place the following script in place of the standard {{ic|bspc monitor -d I II III IV V VI VII VIII IX X}} command:<br />
<br />
{{bc|<nowiki><br />
if [[ $(xrandr -q | grep "DP-1 connected") ]];<br />
then<br />
xrandr --output DP-1 --primary --mode 1920x1080 --pos 0x0 --rotate normal \<br />
--output DVI-I-1 --off \<br />
--output DVI-I-2 --off <br />
bspc monitor DP-1 -d I II III IV V VI VII VIII IX<br />
fi<br />
</nowiki>}}<br />
<br />
The previous script uses [[xrandr]] to set the virtual display configuration and bspc to assign the appropriate desktops layout.<br />
<br />
Note that you should first set your preferred monitor layout with {{Pkg|arandr}}, then export the xrandr configuration script and then copy the contents inside the script in place of the xrandr command.<br />
<br />
=== Rules ===<br />
<br />
bspwm can apply rules to windows based on the class name, which is the second string within the [https://tronche.com/gui/x/icccm/sec-4.html#WM_CLASS WM_CLASS] property specified by [[Wikipedia:Inter-Client Communication Conventions Manual|ICCM]]. To determine the class name, you can:<br />
<br />
# [[Install]] {{Pkg|xorg-xprop}}.<br />
# Run {{ic|xprop {{!}} grep WM_CLASS}}.<br />
# Click on the window of interest to indicate it to {{ic|xprop}}.<br />
# Record the ''second'' string from the output of the command.<br />
<br />
There are two ways to configure window rules (as of [https://github.com/baskerville/bspwm/commit/cd97a3290aa8d36346deb706fa307f5f8faa2f34 cd97a32]).<br />
<br />
The first is by using the built in rule command, as shown in the example bspwmrc:<br />
<br />
{{bc|<nowiki><br />
bspc rule -a Gimp desktop=^8 follow=on state=floating<br />
bspc rule -a Chromium desktop=^2<br />
bspc rule -a mplayer2 state=floating<br />
bspc rule -a Kupfer.py focus=on<br />
bspc rule -a Screenkey manage=off<br />
</nowiki>}}<br />
<br />
The second option is to use an external rule command. This is more complex, but can allow you to craft more complex window rules. See [https://github.com/baskerville/bspwm/tree/master/examples/external_rules these examples] for a sample rule command.<br />
<br />
=== Panels ===<br />
<br />
==== Using lemonbar ====<br />
<br />
An example panel for {{AUR|lemonbar-git}} is provided in the examples folder on the GitHub page. You might also get some insights from the [[lemonbar]] wiki page. The panel will be executed by placing {{ic|panel &}} in your bspwmrc. Check the [[optdepends]] in the {{Pkg|bspwm}} package for dependencies that may be required.<br />
<br />
To display system information on your status bar you can use various system calls. This example will show you how to edit your {{ic|panel}} to get the volume status on your BAR:<br />
<br />
{{bc|<nowiki><br />
panel_volume()<br />
{<br />
volStatus=$(amixer get Master | tail -n 1 | cut -d '[' -f 4 | sed 's/].*//g')<br />
volLevel=$(amixer get Master | tail -n 1 | cut -d '[' -f 2 | sed 's/%.*//g')<br />
# is alsa muted or not muted?<br />
if [ "$volStatus" == "on" ]<br />
then<br />
echo "%{Fyellowgreen} $volLevel %{F-}"<br />
else<br />
# If it is muted, make the font red<br />
echo "%{Findianred} $volLevel %{F-}"<br />
fi<br />
}</nowiki>}}<br />
<br />
Next, we will have to make sure it is called and redirected to {{ic|$PANEL_FIFO}}:<br />
<br />
{{bc|<nowiki><br />
while true; do<br />
echo "S" "$(panel_volume) $(panel_clock)" > "$PANEL_FIFO"<br />
sleep 1s<br />
done &<br />
</nowiki>}}<br />
<br />
==== Using polybar ====<br />
<br />
[[Polybar]] can be used by adding {{ic|polybar ''example'' &}} to your bspwmrc configuration file, where {{ic|''example''}} is the name of the bar.<br />
<br />
=== Scratchpad ===<br />
<br />
==== Using pid ====<br />
<br />
You can emulate a dropdown terminal (like i3's scratchpad feature if you put a terminal in it) using bspwm's window flags. Append the following to the end of the bspwm configuration file (adapt to your own terminal emulator):<br />
<br />
{{Accuracy|{{ic|~/bin/scratch}} is not executed until the st window is shown. As a result, {{ic|/tmp/scratchid}} is not created and the hotkey is not working.}}<br />
<br />
{{bc|<nowiki><br />
bspc rule -a scratchpad sticky=on state=floating hidden=on<br />
# check scratchpad already running<br />
[ "$(ps -x | grep -c 'scratchpad')" -eq "1" ] && st -c scratchpad -e ~/bin/scratch &<br />
</nowiki>}}<br />
<br />
The {{ic|sticky}} flag ensures that the window is always present on the current desktop.<br />
And {{ic|~/bin/scratch}} is:<br />
<br />
{{bc|<nowiki><br />
#!/usr/bin/sh<br />
# only add floating scratchpad window node id to /tmp/scratchid<br />
bspc query -N -n .floating | xargs -i sh -c 'bspc query --node {} -T | grep -q scratchpad && echo {} > /tmp/scratchid'<br />
exec $SHELL<br />
</nowiki>}}<br />
<br />
The hotkey for toggling the scratchpad should be bound to:<br />
<br />
{{bc|<nowiki><br />
id=$(cat /tmp/scratchid);\<br />
bspc node $id --flag hidden;bspc node -f $id<br />
</nowiki>}}<br />
<br />
==== Using class name ====<br />
<br />
In this example we are going to use ''termite'' with a custom class name as our dropdown terminal. It does not have to be ''termite''.<br />
<br />
First create a file in your path with the following content and make it executable. In this example let us call it {{ic|scratchpad.sh}}:<br />
<br />
{{bc|<nowiki><br />
#!/usr/bin/bash<br />
<br />
if [ -z $1 ]; then<br />
echo "Usage: $0 <name of hidden scratchpad window>"<br />
exit 1<br />
fi<br />
<br />
pids=$(xdotool search --class ${1})<br />
for pid in $pids; do<br />
echo "Toggle $pid"<br />
bspc node $pid --flag hidden -f<br />
done<br />
</nowiki>}}<br />
<br />
Then add this to your bspwm config.<br />
<br />
{{bc|<nowiki><br />
...<br />
bspc rule -a dropdown sticky=on state=floating hidden=on<br />
termite --class dropdown -e "zsh -i" &<br />
...<br />
</nowiki>}}<br />
<br />
To toggle the window a custom rule in [[sxhkd]] is necessary. Give as parameter the custom class name.<br />
<br />
{{bc|<nowiki><br />
super + u<br />
scratchpad.sh dropdown<br />
</nowiki>}}<br />
<br />
==== Other ====<br />
<br />
For a scratch-pad which can use any window type without pre-defined rules, see: [https://www.reddit.com/r/bspwm/comments/3xnwdf/i3_like_scratch_for_any_window_possible/cy6i585]<br />
<br />
For a more sophisticated scratchpad script that supports many terminals out of the box and has flags for doing things like optionally starting a tmuxinator/tmux session, turning any window into a scratchpad on the fly, and automatically resizing a scratchpad to fit the current monitor see {{AUR|tdrop-git}}.<br />
<br />
=== Different monitor configurations for different machines ===<br />
<br />
Since the {{ic|bspwmrc}} is a shell script, it allows you to do things like these:<br />
<br />
<nowiki><br />
#!/bin/bash -<br />
<br />
if [[ $HOSTNAME == myhost ]]; then<br />
bspc monitor eDP1 -d I II III IV V VI VII VIII IX X<br />
elif [[ $HOSTNAME == otherhost ]]; then<br />
bspc monitor VGA-0 -d I II III IV V<br />
bspc monitor VGA-1 -d VI VII VIII IX X<br />
elif [[ $HOSTNAME == yetanotherhost ]]; then<br />
bspc monitor DVI-I-3 -d VI VII VIII IX X<br />
bspc monitor DVI-I-2 -d I II III IV V<br />
fi</nowiki><br />
<br />
=== Set up a desktop where all windows are floating ===<br />
<br />
Here is how to setup the desktop 3 to have only floating windows. It can be useful for GIMP or other applications with multiple windows.<br />
<br />
Put this script somewhere in your {{ic|$PATH}} and call it from {{ic|.xinitrc}} or similar (with a {{ic|&}} at the end):<br />
<br />
#!/bin/bash<br />
<nowiki><br />
# change the desktop number here<br />
FLOATING_DESKTOP_ID=$(bspc query -D -d '^3')<br />
<br />
bspc subscribe node_add | while read -a msg ; do<br />
desk_id=${msg[2]}<br />
wid=${msg[4]}<br />
[ "$FLOATING_DESKTOP_ID" = "$desk_id" ] && bspc node "$wid" -t floating<br />
done<br />
</nowiki><br />
<br />
([https://github.com/baskerville/bspwm/issues/428#issuecomment-199985423 source])<br />
<br />
=== Keyboard ===<br />
<br />
Bspwm does not handle any keyboard input and instead provides the ''bspc'' program as its interface.<br />
<br />
For keyboard shortcuts you will have to setup a hotkey daemon like {{Pkg|sxhkd}} ({{AUR|sxhkd-git}} for the development version).<br />
<br />
== Troubleshooting ==<br />
<br />
=== Blank screen and keybindings do not work ===<br />
<br />
* Make sure {{Pkg|sxhkd}} is installed.<br />
* Make sure you are starting ''sxhkd'' (in the background as it is blocking).<br />
* Make sure {{ic|~/.config/bspwm/bspwmrc}} is executable.<br />
* The example configuration file for ''sxhkd'' specifies [[urxvt]] as the terminal emulator. If you do not have this installed, edit {{ic|~/.config/sxhkd/sxhkdrc}} to point to the terminal emulator of your choosing.<br />
<br />
=== Cursor themes do not apply to the desktop ===<br />
<br />
See [[Cursor themes#Change X shaped default cursor]]<br />
<br />
=== Window box larger than the actual application ===<br />
<br />
This can happen if you are using GTK3 applications and usually for dialog windows. Create or add the following: <br />
<br />
{{hc|~/.config/gtk-3.0/gtk.css|<br />
.window-frame, .window-frame:backdrop {<br />
box-shadow: 0 0 0 black;<br />
border-style: none;<br />
margin: 0;<br />
border-radius: 0;<br />
}<br />
<br />
.titlebar {<br />
border-radius: 0;<br />
}<br />
}}<br />
<br />
(source: [https://bbs.archlinux.org/viewtopic.php?pid=1404973#p1404973 Bspwm forum thread])<br />
<br />
=== Problems with Java applications ===<br />
<br />
If you have problems, like Java application Windows not resizing, or menus immediately closing after you click, see [[Java#Gray window, applications not resizing with WM, menus immediately closing]].<br />
<br />
Furthermore, some applications based on Java can not display any window content at all (e.g. Intellij IDEs like PyCharm, CLion, etc). A solution is to install {{Pkg|wmname}} and add the following line in your {{ic|~/.config/bspwm/bspwmrc}}:<br />
<br />
wmname LG3D<br />
<br />
Additionally, these errors can often be solved by setting an environment variable for the JVM within {{ic|bspwmrc}} or a shell rc like {{ic|~/.bashrc}}, since BSPWM is a non reparenting WM.<br />
<br />
export _JAVA_AWT_WM_NONREPARENTING=1<br />
<br />
=== Problems with keybindings using fish ===<br />
<br />
If you use [[fish]], you will find that you are unable to switch desktops. This is because bspc's use of the ^ character is incompatible with fish. You can fix this by explicitly telling sxhkd to use bash to execute commands:<br />
<br />
$ set -U SXHKD_SHELL /usr/bin/bash<br />
<br />
Alternatively, the ^ character may be escaped with a backslash in your sxhkdrc file.<br />
<br />
=== Performance issues using fish ===<br />
<br />
[[sxhkd]] uses the shell set in the SHELL environment variable in order to execute commands. [[fish]] can have long initialization time due to large or improper configuration files, thus all sxhkd commands can take much longer to execute than with other shells. To fix this without changing your default SHELL you can make tell sxhkd explicitly to use bash, or another faster shell to execute commands (for example, sh):<br />
<br />
$ set -U SXHKD_SHELL sh<br />
<br />
=== Error messages "Could not grab key 43 with modfield 68" on start ===<br />
<br />
Either you try to use the same key twice, or you start sxhkd twice. Check bspwmrc and {{ic|~/.profile}} or {{ic|~/.bash_profile}} for excessive commands starting sxhkd.<br />
<br />
== See also ==<br />
<br />
* Mailing List: bspwm ''at'' librelist.com.<br />
* {{ic|#bspwm}} - IRC channel at irc.libera.chat<br />
* [https://matrix.to/#/%23bspwm:matrix.org {{ic|#bspwm:matrix.org}}] - Matrix channel<br />
* https://bbs.archlinux.org/viewtopic.php?id=149444 - Arch BBS thread<br />
* https://github.com/baskerville/bspwm - GitHub project<br />
* https://github.com/windelicato/dotfiles/wiki/bspwm-for-dummies - earsplit's "bspwm for dummies"</div>Moviurohttps://wiki.archlinux.org/index.php?title=Firejail&diff=562345Firejail2019-01-08T08:38:51Z<p>Moviuro: /* Troubleshooting */ --net options fail with firejail 0.5.96 and linux >= 4.20.0</p>
<hr />
<div>[[Category:Sandboxing]]<br />
[[ja:Firejail]]<br />
{{Related articles start}}<br />
{{Related|Security}}<br />
{{Related articles end}}<br />
[https://firejail.wordpress.com/ Firejail] is an easy to use SUID sandbox program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces, seccomp-bpf and Linux capabilities.<br />
<br />
== Installation ==<br />
<br />
[[Install]] either {{Pkg|firejail}}, {{aur|firejail-git}} or the {{aur|firejail-apparmor}} package. A GUI application for use with Firejail is also available, {{aur|firetools}}.<br />
<br />
{{Note|For information about {{man|7|user_namespaces}} support in Arch Linux kernels see [[Security#Sandboxing applications]]. [https://github.com/netblue30/firejail/issues/1842#issuecomment-376642039 Firejail can use it even if it is disabled].}}<br />
{{Warning|While upstream is gradually adopting whitelists, (cf {{ic|/etc/firejail/firefox.profile}},) most of the supplied profiles still rely heavily on blacklists. This means that anything not explicitly forbidden by the profile will be accessible to the application. For example, if you have btrfs snapshots available in {{ic|/mnt/btrfs}}, a jailed program may be forbidden from accessing {{ic|$HOME/.ssh}}, but would still be able to access {{ic|/mnt/btrfs/@some-snapshot/$HOME/.ssh}}. Make sure to audit your profiles, see [[#Testing profiles]]}}<br />
<br />
=== Apparmor integration ===<br />
<br />
Since 0.9.42, {{aur|firejail-apparmor}}, has supported more direct integration with Apparmor through a generic apparmor profile. During installation, the profile, {{ic|firejail-default}}, is placed in {{ic|/etc/apparmor.d}} directory, and needs to be loaded into the kernel by running the following command as root:<br />
<br />
# apparmor_parser -r /etc/apparmor.d/firejail-default<br />
<br />
To quote the manual: <br />
<br />
:''The installed profile is supplemental for main firejail functions and among other things does the following:''<br />
<br />
::''- Disable ptrace. With ptrace it is possible to inspect and hijack running programs. Usually this is needed only for debugging.''<br />
<br />
::''- Whitelist write access to several files under /run, /proc and /sys.''<br />
<br />
::''- Allow running programs only from well-known system paths, such as /bin, /sbin, /usr/bin etc. Those paths are available as read-only. Running programs and scripts from user home or other directories writable by the user is not allowed.''<br />
<br />
::''- Prevent using non-standard network sockets. Only unix, inet, inet6, netlink, raw and packet are allowed.''<br />
<br />
::''- Deny access to known sensitive paths like .snapshots.''<br />
<br />
Local customizations of the apparmor profile are supported by editing the file {{ic|/etc/apparmor.d/local/firejail-local}}<br />
<br />
== Configuration ==<br />
<br />
Most users will not require any custom configuration and can proceed to [[#Usage]].<br />
<br />
Firejail uses profiles to set the security protections for each of the applications executed inside of it - you can find the default profiles in {{ic|/etc/firejail/''application''.profile}}. Should you require custom profiles for applications not included, or wish to modify the defaults, you may place new rules or copies of the defaults in the {{ic|~/.config/firejail/}} directory. You may have multiple custom profile files for a single application, and you may share the same profile file among several applications.<br />
<br />
If firejail does not have a profile for a particular application, it uses its restrictive system-wide default profile. This can result in the application not functioning as desired, without first creating a custom, and less restrictive profile.<br />
<br />
Refer to {{man|5|firejail-profile}}.<br />
<br />
== Usage ==<br />
<br />
To execute an application using firejail's default protections for that application (the default profile), execute the following:<br />
<br />
$ firejail <program name><br />
<br />
One-time additions to the default profile can be added as command line options (see the man page). For example, to execute ''okular'' with seccomp protection, execute the following:<br />
<br />
$ firejail --seccomp okular<br />
<br />
You may define multiple non-default profiles for a single program. Once you create your profile file, you can use it by executing:<br />
<br />
$ firejail --profile=/absolute/path/to/profile <program name><br />
<br />
=== Using Firejail by default ===<br />
<br />
To use Firejail by default for all applications for which it has profiles, run the ''firecfg'' tool as root.<br />
<br />
# firecfg<br />
<br />
This creates symbolic links in {{ic|/usr/local/bin}} pointing to {{ic|/usr/bin/firejail}}, for all programs for which firejail has default profiles.<br />
<br />
{{Tip|A [[pacman hook]] can be used to automatically run {{ic|firecfg}} on [[pacman]] operations:<br />
{{hc|/etc/pacman.d/hooks/firejail.hook|2=<br />
[Trigger]<br />
Type = File<br />
Operation = Install<br />
Operation = Upgrade<br />
Operation = Remove<br />
Target = usr/bin/*<br />
Target = usr/local/bin/*<br />
Target = usr/share/applications/*.desktop<br />
<br />
[Action]<br />
Description = Configure symlinks in /usr/local/bin based on firecfg.config...<br />
When = PostTransaction<br />
Depends = firejail<br />
Exec = /bin/sh -c 'firecfg &>/dev/null'}}}}<br />
<br />
To manually map individual applications execute:<br />
<br />
# ln -s /usr/bin/firejail /usr/local/bin/<application><br />
<br />
{{Note|1=<nowiki></nowiki><br />
* {{ic|/usr/local/bin}} should be set before {{ic|/usr/bin}} in the {{ic|PATH}} [[environment variable]].<br />
* To run a symbolic program with custom Firejail setting, simple prefix ''firejail'' as seen in [[#Usage]].<br />
* For a daemon, you will need to overwrite the systemd unit file for that daemon to call firejail, see [[systemd#Editing provided units]].<br />
* {{ic|firecfg}} doesn't work with some cli shells such as: {{ic|tar}}, {{ic|curl}}, {{ic|wget}}, and {{ic|git}} which need to be symlinked manually.<br />
* Symbolic links to {{ic|gzip}} and {{ic|xz}} interfere with {{ic|makepkg}}'s ability to preload {{ic|libfakeroot.so}}. See [https://bbs.archlinux.org/viewtopic.php?id=230913 BBS#230913].}}<br />
<br />
{{Warning|Upstream provides profiles for {{ic|gpg}} and {{ic|gpg-agent}}. If gpg is symlinked with the supplied profile, pacman will be unable to update {{pkg|archlinux-keyring}}.}}<br />
<br />
=== Enable AppArmor support ===<br />
There are a number of ways to enable [[AppArmor]] confinement on top of a Firejail security profile:<br />
<br />
* Pass the {{ic|--apparmor}} flag to Firejail in the command line, e.g. {{ic|$ firejail --apparmor firefox}}<br />
* Use a custom profile.<br />
* Enable Apparmor globally in {{ic|/etc/firejail/globals.local}} and disable as needed through the use of {{ic|ignore apparmor}} in {{ic|/etc/firejail/<ProgramName>.local}}.<br />
<br />
=== Verifying Firejail is being used ===<br />
<br />
$ firejail --list<br />
<br />
== Creating custom profiles ==<br />
<br />
=== Whitelists and Blacklists ===<br />
<br />
Blacklists are permissive:<br />
<br />
* Permit everything not explicitly forbidden: {{ic|blacklist <location/file>}}<br />
* Permit file or location in any later blacklist: {{ic|noblacklist <location/file>}} <br />
<br />
Whitelists are restrictive: <br />
<br />
* Forbid everything not explicitly permitted: {{ic|whitelist <location/file>}}<br />
* Forbid file or location in any later whitelist: {{ic|nowhitelist <location/file>}}<br />
<br />
=== Profile writing ===<br />
<br />
The basic process is:<br />
<br />
# Copy the default profile (which uses blacklists) to your work folder and give it a unique name:<br />
# Change the line {{ic|include /etc/firejail/default.local}} to {{ic|include /etc/firejail/ProfileName.local}}<br />
# Gradually comment/uncomment the various options while checking at each stage that the application runs inside the new sandbox<br />
# Desirable options not available in the copied default profile can be found by consulting the manual<br />
# [https://firejail.wordpress.com/documentation-2/building-whitelisted-profiles/ Build a whitelist] of permitted locations. For portability, it may be advisable to place at least some of this list it in a {{ic|.local}} file<br />
# Test the profile for security holes, see [[#Testing profiles]]<br />
# Once satisfied, copy your new profile to either {{ic|/etc/firejail/}} or {{ic|~/.config/firejail/}}<br />
<br />
You may find the following to be useful:<br />
<br />
# {{ic|firejail --debug $OtherOptions $PathToProfile $Program > $PathToOutputFile}} Gives a detailed breakdown of the sandbox<br />
# {{ic|firejail --debug-caps}} gives a list of caps supported by the current Firejail software build. This is useful when building a [https://l3net.wordpress.com/2015/03/16/firejail-linux-capabilities-guide/ caps whitelist].<br />
# {{ic|firejail --help}} for a full list of {{ic|--debug}} options<br />
# {{ic|firemon PID}} monitors the running process. See {{ic|firemon --help}} for details<br />
# {{Pkg|checksec}} may also be useful in testing which standard security features are being used<br />
<br />
{{Note|<nowiki></nowiki><br />
* The idea is to be as restrictive as possible, while still maintaining usability. This may involve sacrificing potentially dangerous functionality and a change in cavalier work habits.<br />
* By default, seccomp filters work on a blacklist (which can be found in the manual). It is possible to use {{ic|seccomp.keep}} to build a custom whitelist of filters for an application. [https://firejail.wordpress.com/documentation-2/seccomp-guide/].<br />
* The list of possible options for a firejail profile is extensive, and users should consult the firejail-profile(5) man page.<br />
}}<br />
<br />
==== Persistent local customisation ====<br />
<br />
The standard profile layout now includes the capability to make persistent local customisations through the inclusion of {{ic|.local}} files. Basically, each officially supported profile contains the lines {{ic|include /etc/firejail/ProgramName.local}} and {{ic|include /etc/firejail/globals.local}}. Since the order of precedence is determined by which is read first, this makes for a very powerful way of making local customisations.<br />
For example, with reference [https://github.com/netblue30/firejail/issues/1510#issuecomment-326443650 this firejail question], to globally enable Apparmor and disable Internet connectivity, one could simply create/edit {{ic|/etc/firejail/globals.local}} to include the lines<br />
<br />
# enable Apparmor and disable Internet globally<br />
net none<br />
apparmor<br />
<br />
Then, to allow, for example, "curl" to connect to the internet, yet still maintain its apparmor confinement, one would create/edit {{ic|/etc/firejail/curl.local}} to include the lines.<br />
<br />
# enable internet for curl<br />
ignore net<br />
<br />
Since {{ic|curl.local}} is read before {{ic|globals.local}}, {{ic|ignore net}} overrides {{ic|net none}}, and, as a bonus, the above changes would be persistent across future updates.<br />
<br />
=== Testing profiles ===<br />
<br />
Firejail's built in audit feature allows the user to find gaps in a security profile by replacing the program to be sandboxed with a test program. By default, firejail uses the {{ic|faudit}} program distributed with Firejail. (Note: A custom test program supplied by the user can also be used.) <br />
Examples:<br />
<br />
# Run the default audit program: {{ic|$ firejail --audit transmission-gtk}}<br />
# Run a custom audit program: {{ic|1=$ firejail --audit=~/sandbox-test transmission-gtk}} <br />
<br />
In the examples above, the sandbox configures the transmission-gtk profile and starts the test program. The real program, transmission-gtk, will not be started.<br />
<br />
{{Note|The audit feature is not implemented for --x11 commands.}}<br />
<br />
== Firejail with Xephyr ==<br />
<br />
[[Xephyr]] will allow you to sandbox [[Xorg]]. If you want to be able to resize windows, install a window manager such as [[Openbox]].<br />
<br />
{{ic|xephyr-screen ''Width''x''Height''}} can be set in {{ic|/etc/firejail/firejail.config}} where {{ic|''Width''}} and {{ic|''Height''}} are in pixels and based on your screen resolution.<br />
<br />
To open the sandbox:<br />
<br />
$ firejail --x11 --net=''device'' openbox<br />
<br />
{{ic|''device''}} is your active [[network interface]]. Then right click and select your applications to run.<br />
<br />
{{Note|If you use [[Unbound]], [[dnsmasq]], [[Pdnsd]] or any other local cache as your resolver on 127.0.0.1 for example, you would leave {{ic|1=--net=''device''}} out of the command as your network should work automatically.}}<br />
<br />
A great guide can be found on the [https://firejail.wordpress.com/documentation-2/x11-guide/#configurexephyr Firejail Wordpress].<br />
<br />
According to the guide:<br />
<br />
:The sandbox replaces the regular X11 server with Xpra or Xephyr server. This prevents X11 keyboard loggers and screenshot utilities from accessing the main X11 server.<br />
<br />
Note that the statement:<br />
<br />
:The only way to disable the abstract socket {{ic|@/tmp/.X11-unix/X0}} is by using a network namespace. If for any reasons you cannot use a network namespace, the abstract socket will still be visible inside the sandbox. Hackers can attach keylogger and screenshot programs to this socket.<br />
<br />
is incorrect, [[Xinit#xserverrc|xserverrc]] can be edited to {{ic|-nolisten local}} which disables the abstract sockets of X11 and helps isolate it.<br />
<br />
=== Sandboxing a browser ===<br />
<br />
[[Openbox]] can be configured to start a certain browser at startup. {{ic|''program''.profile}} is the respective profile contained in {{ic|/etc/firejail}}, and {{ic|--startup "''command''"}} is the command line used to start the program. For example, to start Chromium in the sandbox:<br />
<br />
$ firejail --x11 --profile=/etc/firejail/chromium.profile openbox --startup "chromium"<br />
<br />
==Tips and tricks==<br />
<br />
=== Paths containing spaces ===<br />
<br />
If you need to reference, whitelist, or blacklist a directory within a custom profile, such as with {{aur|palemoon}}, you must do so using the absolute path, without encapsulation or escapes:<br />
/home/user/.moonchild productions<br />
<br />
===Private mode===<br />
<br />
Firejail also includes a one time private mode, in which no mounts are made in the chroots to your home directory. In doing this, you can execute applications without performing any changes to disk. For example, to execute okular in private mode, do the following:<br />
<br />
$ firejail --seccomp --private okular<br />
<br />
== Troubleshooting ==<br />
<br />
Some applications do not work properly with Firejail, and others simply require special configuration. In the instance any directories are disallowed or blacklisted for any given application, you may have to further edit the profile to enable nonstandard directories that said application needs to access. One example is wine; wine will not work with seccomp in most cases.<br />
<br />
Other configurations exist; it is suggested you check out the man page for firejail to see them all, as firejail is in rapid development.<br />
<br />
=== Remove Firejail symbolic links ===<br />
<br />
To remove Firejail created symbolic links (e.g. reset to default):<br />
<br />
# firecfg --clean<br />
<br />
Verify if any leftovers of [[Desktop entries]] are still overruled by Firejail.<br />
<br />
=== Desktop files ===<br />
<br />
Some GUI application launchers ({{ic|.desktop}} files) are coded using absolute paths to an executable, which circumvents firejail's symlink method of ensuring that it is being used. The ''firecfg'' tool includes an option to over-ride this on a per-user basis by copying the {{ic|.desktop}} files from {{ic|/usr/share/applications/*.desktop}} to {{ic|~/.local/share/applications/}} and replacing the absolute paths with simple file names.<br />
<br />
$ firecfg --fix<br />
<br />
There may be cases for which you need to manually modify the EXEC line of the {{ic|.desktop}} file in {{ic|~/.local/share/applications/}} to explicitly call Firejail.<br />
<br />
=== PulseAudio ===<br />
{{Note|Using PulseAudio version 9.0 or later should fix this issue.}}<br />
<br />
If Firejail causes [[PulseAudio]] issues with sandboxed applications [https://firejail.wordpress.com/support/known-problems/#pulseaudio], the following command may be used:<br />
<br />
$ firecfg --fix-sound<br />
<br />
This commands creates a custom {{ic|~/.config/pulse/client.conf}} file for the ''current'' user with {{ic|1=enable-shm = no}} and possible other workarounds.<br />
<br />
=== Hidepid ===<br />
<br />
If you have [[hidepid]] installed, Firemon can only be run as root. This, among other things, will cause problems with the Firetools GUI incorrectly reporting "Capabilities", "Protocols" and the status of "Seccomp". See [https://github.com/netblue30/firejail/issues/1564]<br />
<br />
=== Proprietary Nvidia drivers ===<br />
<br />
Some users report problems when using Firejail and proprietary graphic drivers from [[NVIDIA]] (e.g. [https://github.com/netblue30/firejail/issues/1753], [https://github.com/netblue30/firejail/issues/879] or [https://github.com/netblue30/firejail/issues/841]). This can often be solved by disabling the {{ic|noroot}} Firejail option in the application's profile file.<br />
<br />
=== --net options and Linux kernel >=4.20.0 ===<br />
<br />
There is a bug on firejail 0.5.96 with linux >= 4.20.0, see [https://github.com/netblue30/firejail/issues/2314] and [https://github.com/netblue30/firejail/pull/2327]<br />
<br />
Example error message:<br />
<br />
$ firejail --noprofile --net=eth0 ls<br />
Parent pid 8521, child pid 8522<br />
Error send: arp.c:182 arp_check: Invalid argument<br />
Error: proc 8521 cannot sync with peer: unexpected EOF<br />
Peer 8522 unexpectedly exited with status 1<br />
<br />
==See also==<br />
* [https://github.com/netblue30/firejail Firejail GitHub project page]<br />
* [[bubblewrap]], a minimal alternative to Firejail</div>Moviurohttps://wiki.archlinux.org/index.php?title=WireGuard&diff=532685WireGuard2018-08-07T18:55:36Z<p>Moviuro: /* Setup a VPN server */ Fix subnets, add comments + add example for a client that doesn't tunnel everything</p>
<hr />
<div>[[Category:Virtual Private Network]]<br />
[[ja:WireGuard]]<br />
From the [https://www.wireguard.com/ WireGuard] project homepage: <br />
:Wireguard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPSec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. WireGuard is designed as a general purpose VPN for running on embedded interfaces and super computers alike, fit for many different circumstances. Initially released for the Linux kernel, it plans to be cross-platform and widely deployable. It is currently under heavy development, but already it might be regarded as the most secure, easiest to use, and simplest VPN solution in the industry.<br />
<br />
{{Warning|''WireGuard has not undergone proper degrees of security auditing and the protocol is still subject to change.''[https://www.wireguard.com/#work-in-progress]}}<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|wireguard-tools}} package.<br />
<br />
== Usage ==<br />
<br />
To create a public and private key<br />
<br />
cd /etc/wireguard<br />
wg genkey | tee privatekey | wg pubkey > publickey<br />
chmod 600 privatekey # /etc/wireguard is already 700 but you're never too safe<br />
<br />
Below commands will demonstrate how to setup a basic tunel between two peers with the following settings:<br />
<br />
{| class="wikitable"<br />
! <br />
! Peer A<br />
! Peer B<br />
|----------------------------------------------------------<br />
| External IP address<br />
| 10.10.10.1/24<br />
| 10.10.10.2/24<br />
|----------------------------------------------------------<br />
| Internal IP address<br />
| 10.0.0.1/24<br />
| 10.0.0.2/24<br />
|----------------------------------------------------------<br />
| wireguard listening port<br />
| UDP/48574<br />
| UDP/39814<br />
|}<br />
<br />
The external addresses should already exist. For example, peer A should be able to ping peer B via {{ic|ping 10.10.10.2}}, and vice versa. The internal addresses will be new addresses created by the {{ic|ip}} commands below and will be shared internally within the new WireGuard network. The {{ic|/24}} in the IP addresses is the [[wikipedia:Classless_Inter-Domain_Routing#CIDR_notation|CIDR]].<br />
<br />
==== Peer A setup ====<br />
<br />
This peer will listen on UDP port 48574 and will accept connection from peer B by linking its public key with both its inner and outer IPs addresses.<br />
<br />
ip link add dev wg0 type wireguard<br />
ip addr add 10.0.0.1/24 dev wg0<br />
wg set wg0 listen-port 48574 private-key /etc/wireguard/privatekey<br />
wg set wg0 peer [Peer B public key] persistent-keepalive 25 allowed-ips 10.0.0.2/32 endpoint 10.10.10.2:39814<br />
ip link set wg0 up<br />
<br />
{{ic|[Peer B public key]}} should have the same format as {{ic|1=EsnHH9m6RthHSs+sd9uM6eCHe/mMVFaRh93GYadDDnM=}}. {{ic|allowed-ips}} is a list of addresses that peer A will be able to send traffic to. {{ic|allowed-ips 0.0.0.0/0}} would allow sending traffic to any address.<br />
<br />
==== Peer B setup ====<br />
<br />
As with Peer A, whereas the wireguard daemon is listening on the UDP port 39814 and accept connection from peer A only.<br />
<br />
ip link add dev wg0 type wireguard<br />
ip addr add 10.0.0.2/24 dev wg0<br />
wg set wg0 listen-port 39814 private-key /etc/wireguard/privatekey<br />
wg set wg0 peer [Peer A public key] persistent-keepalive 25 allowed-ips 10.0.0.1/32 endpoint 10.10.10.1:48574<br />
ip link set wg0 up<br />
<br />
==== Basic checkups ====<br />
Invoking the wg command without parameter will give a quick overview of the current configuration.<br />
<br />
As an example, when Peer A has been configured we are able to see its identity and its associated peers:<br />
<br />
peer-a$ wg<br />
interface: wg0<br />
public key: UguPyBThx/+xMXeTbRYkKlP0Wh/QZT3vTLPOVaaXTD8=<br />
private key: (hidden)<br />
listening port: 48574<br />
<br />
peer: 9jalV3EEBnVXahro0pRMQ+cHlmjE33Slo9tddzCVtCw=<br />
endpoint: 10.10.10.2:39814<br />
allowed ips: 10.0.0.2/32<br />
<br />
At this point one could reach the end of the tunnel:<br />
peer-a$ ping 10.0.0.2<br />
<br />
==== Persistent configuration ====<br />
<br />
The config can be saved by utilizing {{ic|showconf}}<br />
wg showconf wg0 > /etc/wireguard/wg0.conf<br />
wg setconf wg0 /etc/wireguard/wg0.conf<br />
<br />
== Setup a VPN server ==<br />
<br />
Wireguard comes with a tool to quickly create and tear down VPN servers and clients, {{ic|wg-quick}}. Note that the config file used here is not a valid config file that can be used with {{ic|wg setconf}}.<br />
<br />
==== Server ====<br />
<br />
{{hc|1=/etc/wireguard/wg0server.conf|2=<br />
[Interface]<br />
Address = 10.200.100.1/24 # This is the virtual IP address, with the subnet mask we will use for the VPN<br />
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE<br />
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE<br />
ListenPort = 51820<br />
PrivateKey = [SERVER PRIVATE KEY]<br />
<br />
[Peer]<br />
PublicKey = [CLIENT PUBLIC KEY]<br />
AllowedIPs = 10.200.100.2/32 # This denotes the clients IP with a /32: the client only has ONE IP.<br />
}}<br />
<br />
In order for the iptables rules to work, IPv4 forwarding should be enabled:<br />
sysctl net.ipv4.ip_forward=1<br />
<br />
To make the change permanent, add {{ic|1=net.ipv4.ip_forward = 1}} to {{ic|/etc/sysctl.d/99-sysctl.conf}}.<br />
<br />
Bring the interface up by using {{ic|wg-quick up wg0server}}, and use {{ic|wg-quick down wg0server}} to bring it down.<br />
<br />
==== Client (tunnel all traffic) ====<br />
<br />
{{hc|1=/etc/wireguard/wg0.conf|2=<br />
[Interface]<br />
Address = 10.200.100.2/24 # The client IP from wg0server.conf with the same subnet mask<br />
PrivateKey = [CLIENT PRIVATE KEY]<br />
DNS = 10.200.100.1<br />
<br />
[Peer]<br />
PublicKey = [SERVER PUBLICKEY]<br />
AllowedIPs = 0.0.0.0/0, ::0/0<br />
Endpoint = [SERVER ENDPOINT]:51820<br />
PersistentKeepalive = 25<br />
}}<br />
Bring this interface up by using {{ic|wg-quick up wg0}}, and use {{ic|wg-quick down wg0}} to bring it down.<br />
<br />
To bring this up automatically one can use {{ic|systemctl enable wg-quick@wg0}}<br />
<br />
If you use [[NetworkManager]], it may be necessary to also enable NetworkManager-wait-online.service {{ic|systemctl enable NetworkManager-wait-online.service}}<br />
<br />
or if you're using systemd-networkd, to enable systemd-networkd-wait-online.service {{ic|systemctl enable systemd-networkd-wait-online.service}}<br />
<br />
to wait until devices are network ready before attempting wireguard connection.<br />
<br />
==== Client (don't tunnel all traffic) ====<br />
<br />
{{hc|1=/etc/wireguard/wg0.conf|2=<br />
[Interface]<br />
Address = 10.200.100.2/24 # The client IP from wg0server.conf with the same subnet mask<br />
PrivateKey = [CLIENT PRIVATE KEY]<br />
DNS = 10.200.100.1<br />
<br />
[Peer]<br />
PublicKey = [SERVER PUBLICKEY]<br />
AllowedIPs = 10.200.100.0/24, 10.123.45.0/24, 1234:4567:89ab::/48 # Denotes all subnets that are available only through the VPN server<br />
Endpoint = [SERVER ENDPOINT]:51820<br />
PersistentKeepalive = 25<br />
}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== DKMS module not available ===<br />
<br />
If the following command does not list any module after you installed {{pkg|wireguard-dkms}},<br />
<br />
$ modprobe wireguard && lsmod | grep wireguard<br />
<br />
or if creating a new link returns<br />
<br />
# ip link add dev wg0 type wireguard<br />
RTNETLINK answers: Operation not supported<br />
<br />
you probably miss the linux headers.<br />
<br />
These headers are available in {{pkg|linux-headers}} or {{pkg|linux-lts-headers}} depending of the kernel installed on your system.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Store private keys in encrypted form ===<br />
<br />
It may be desirable to store private keys in encrypted form, such as through use of {{pkg|pass}}. Just replace the PrivateKey line under [Interface] in your config file with:<br />
<br />
PostUp = wg set %i private-key <(su user -c "export PASSWORD_STORE_DIR=/path/to/your/store/; pass WireGuard/private-keys/%i")<br />
<br />
where user is your username. See the `wg-quick(8)` man page for more details.</div>Moviurohttps://wiki.archlinux.org/index.php?title=WireGuard&diff=532682WireGuard2018-08-07T18:47:22Z<p>Moviuro: Remove # from command lines where unnecessary - only letting $ where appropriate + using the /etc/wireguard directory</p>
<hr />
<div>[[Category:Virtual Private Network]]<br />
[[ja:WireGuard]]<br />
From the [https://www.wireguard.com/ WireGuard] project homepage: <br />
:Wireguard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPSec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. WireGuard is designed as a general purpose VPN for running on embedded interfaces and super computers alike, fit for many different circumstances. Initially released for the Linux kernel, it plans to be cross-platform and widely deployable. It is currently under heavy development, but already it might be regarded as the most secure, easiest to use, and simplest VPN solution in the industry.<br />
<br />
{{Warning|''WireGuard has not undergone proper degrees of security auditing and the protocol is still subject to change.''[https://www.wireguard.com/#work-in-progress]}}<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|wireguard-tools}} package.<br />
<br />
== Usage ==<br />
<br />
To create a public and private key<br />
<br />
cd /etc/wireguard<br />
wg genkey | tee privatekey | wg pubkey > publickey<br />
chmod 600 privatekey # /etc/wireguard is already 700 but you're never too safe<br />
<br />
Below commands will demonstrate how to setup a basic tunel between two peers with the following settings:<br />
<br />
{| class="wikitable"<br />
! <br />
! Peer A<br />
! Peer B<br />
|----------------------------------------------------------<br />
| External IP address<br />
| 10.10.10.1/24<br />
| 10.10.10.2/24<br />
|----------------------------------------------------------<br />
| Internal IP address<br />
| 10.0.0.1/24<br />
| 10.0.0.2/24<br />
|----------------------------------------------------------<br />
| wireguard listening port<br />
| UDP/48574<br />
| UDP/39814<br />
|}<br />
<br />
The external addresses should already exist. For example, peer A should be able to ping peer B via {{ic|ping 10.10.10.2}}, and vice versa. The internal addresses will be new addresses created by the {{ic|ip}} commands below and will be shared internally within the new WireGuard network. The {{ic|/24}} in the IP addresses is the [[wikipedia:Classless_Inter-Domain_Routing#CIDR_notation|CIDR]].<br />
<br />
==== Peer A setup ====<br />
<br />
This peer will listen on UDP port 48574 and will accept connection from peer B by linking its public key with both its inner and outer IPs addresses.<br />
<br />
ip link add dev wg0 type wireguard<br />
ip addr add 10.0.0.1/24 dev wg0<br />
wg set wg0 listen-port 48574 private-key /etc/wireguard/privatekey<br />
wg set wg0 peer [Peer B public key] persistent-keepalive 25 allowed-ips 10.0.0.2/32 endpoint 10.10.10.2:39814<br />
ip link set wg0 up<br />
<br />
{{ic|[Peer B public key]}} should have the same format as {{ic|1=EsnHH9m6RthHSs+sd9uM6eCHe/mMVFaRh93GYadDDnM=}}. {{ic|allowed-ips}} is a list of addresses that peer A will be able to send traffic to. {{ic|allowed-ips 0.0.0.0/0}} would allow sending traffic to any address.<br />
<br />
==== Peer B setup ====<br />
<br />
As with Peer A, whereas the wireguard daemon is listening on the UDP port 39814 and accept connection from peer A only.<br />
<br />
ip link add dev wg0 type wireguard<br />
ip addr add 10.0.0.2/24 dev wg0<br />
wg set wg0 listen-port 39814 private-key /etc/wireguard/privatekey<br />
wg set wg0 peer [Peer A public key] persistent-keepalive 25 allowed-ips 10.0.0.1/32 endpoint 10.10.10.1:48574<br />
ip link set wg0 up<br />
<br />
==== Basic checkups ====<br />
Invoking the wg command without parameter will give a quick overview of the current configuration.<br />
<br />
As an example, when Peer A has been configured we are able to see its identity and its associated peers:<br />
<br />
peer-a$ wg<br />
interface: wg0<br />
public key: UguPyBThx/+xMXeTbRYkKlP0Wh/QZT3vTLPOVaaXTD8=<br />
private key: (hidden)<br />
listening port: 48574<br />
<br />
peer: 9jalV3EEBnVXahro0pRMQ+cHlmjE33Slo9tddzCVtCw=<br />
endpoint: 10.10.10.2:39814<br />
allowed ips: 10.0.0.2/32<br />
<br />
At this point one could reach the end of the tunnel:<br />
peer-a$ ping 10.0.0.2<br />
<br />
==== Persistent configuration ====<br />
<br />
The config can be saved by utilizing {{ic|showconf}}<br />
wg showconf wg0 > /etc/wireguard/wg0.conf<br />
wg setconf wg0 /etc/wireguard/wg0.conf<br />
<br />
== Setup a VPN server ==<br />
<br />
Wireguard comes with a tool to quickly create and tear down VPN servers and clients, {{ic|wg-quick}}. Note that the config file used here is not a valid config file that can be used with {{ic|wg setconf}}.<br />
<br />
==== Server ====<br />
<br />
{{hc|1=/etc/wireguard/wg0server.conf|2=<br />
[Interface]<br />
Address = 10.200.100.1/24<br />
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE<br />
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE<br />
ListenPort = 51820<br />
PrivateKey = [SERVER PRIVATE KEY]<br />
<br />
[Peer]<br />
PublicKey = [CLIENT PUBLIC KEY]<br />
AllowedIPs = 10.200.100.2/32 # This denotes the clients IP.<br />
}}<br />
<br />
In order for the iptables rules to work, IPv4 forwarding should be enabled:<br />
sysctl net.ipv4.ip_forward=1<br />
<br />
To make the change permanent, add {{ic|1=net.ipv4.ip_forward = 1}} to {{ic|/etc/sysctl.d/99-sysctl.conf}}.<br />
<br />
Bring the interface up by using {{ic|wg-quick up wg0server}}, and use {{ic|wg-quick down wg0server}} to bring it down.<br />
<br />
==== Client ====<br />
<br />
{{hc|1=/etc/wireguard/wg0.conf|2=<br />
[Interface]<br />
Address = 10.200.100.2/32 # The client IP from wg0server.conf<br />
PrivateKey = [CLIENT PRIVATE KEY]<br />
DNS = 10.200.100.1<br />
<br />
[Peer]<br />
PublicKey = [SERVER PUBLICKEY]<br />
AllowedIPs = 0.0.0.0/0<br />
Endpoint = [SERVER ENDPOINT]:51820<br />
PersistentKeepalive = 25<br />
}}<br />
Bring this interface up by using {{ic|wg-quick up wg0}}, and use {{ic|wg-quick down wg0}} to bring it down.<br />
<br />
To bring this up automatically one can use {{ic|systemctl enable wg-quick@wg0}}<br />
<br />
If you use [[NetworkManager]], it may be necessary to also enable NetworkManager-wait-online.service {{ic|systemctl enable NetworkManager-wait-online.service}}<br />
<br />
or if you're using systemd-networkd, to enable systemd-networkd-wait-online.service {{ic|systemctl enable systemd-networkd-wait-online.service}}<br />
<br />
to wait until devices are network ready before attempting wireguard connection.<br />
<br />
== Troubleshooting ==<br />
<br />
=== DKMS module not available ===<br />
<br />
If the following command does not list any module after you installed {{pkg|wireguard-dkms}},<br />
<br />
$ modprobe wireguard && lsmod | grep wireguard<br />
<br />
or if creating a new link returns<br />
<br />
# ip link add dev wg0 type wireguard<br />
RTNETLINK answers: Operation not supported<br />
<br />
you probably miss the linux headers.<br />
<br />
These headers are available in {{pkg|linux-headers}} or {{pkg|linux-lts-headers}} depending of the kernel installed on your system.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Store private keys in encrypted form ===<br />
<br />
It may be desirable to store private keys in encrypted form, such as through use of {{pkg|pass}}. Just replace the PrivateKey line under [Interface] in your config file with:<br />
<br />
PostUp = wg set %i private-key <(su user -c "export PASSWORD_STORE_DIR=/path/to/your/store/; pass WireGuard/private-keys/%i")<br />
<br />
where user is your username. See the `wg-quick(8)` man page for more details.</div>Moviurohttps://wiki.archlinux.org/index.php?title=Talk:Intel_graphics&diff=517690Talk:Intel graphics2018-04-16T20:09:19Z<p>Moviuro: /* Dirver "modesetting" is nowhere to be found */ re re</p>
<hr />
<div>== [drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic update failure on pipe A ==<br />
<br />
Maybe the solution to get rid of the above dmesg log spamming could be mentioned? You just add `options i915 enable_psr=0` to the file `/etc/modprobe.d/i915.conf`. [[User:Bjourne|Bjourne]] ([[User talk:Bjourne|talk]]) 17:04, 19 August 2016 (UTC)<br />
<br />
== Backlight is not adjustable after trying various acpi_osi values ==<br />
<br />
[http://unix.stackexchange.com/q/315178/3645 Full details] on Stack Exchange.<br />
<br />
{{unsigned|20:04, 8 October 2016|L0b0}}<br />
<br />
== DRI3 confusion ==<br />
<br />
I've seen in the forum people ask from time to time how to enable DRI3 on their system.<br />
<br />
As stated many times there, DRI3 should be on for most (if not all) of them. But people keep telling them to check<br />
<br />
cat /var/log/Xorg.0.log | grep DRI<br />
<br />
which shows up this message:<br />
<br />
GLX: Initialized DRI2 GL provider for screen 0<br />
<br />
which is *not accurate*.<br />
<br />
If you run this command instead:<br />
<br />
LC_ALL=C LIBGL_DEBUG=verbose glxinfo | grep DRI<br />
<br />
you might stump with this other message:<br />
<br />
libGL: Using DRI3 for screen 0<br />
<br />
which proves you are using DRI3 even though X11 doesn't reply with the correct information.<br />
<br />
The command was adapted from [https://lists.x.org/archives/xorg-devel/2014-June/042735.html xorg mailing list].<br />
<br />
So, it think adding this information in the page could be of major interest. What do you think?<br />
<br />
[[User:Franzrogar|Franzrogar]] ([[User talk:Franzrogar|talk]]) 07:01, 4 November 2016 (UTC)<br />
<br />
== Guide for screen scaling with external displays via xrandr? ==<br />
<br />
I tried to find instructions for scaling the display resolution without stretching on this wiki page, but the section only says that it's not implemented in the Intel drivers yet. However, [https://unix.stackexchange.com/questions/220387/how-to-set-scaling-mode-for-external-displays-on-intel-gpu this stackexchange thread] has a workaround using an xrandr transform matrix. Should this be added to the wiki page?<br />
<br />
[[User:Ibara|Ibara]] ([[User talk:Ibara|talk]]) 12:35, 22 May 2017 (UTC)<br />
<br />
== <s>Dirver "modesetting" is nowhere to be found</s> ==<br />
<br />
Driver "modesetting" does not appear in the wiki. It would have saved me around 5 hours of pointless mouse-chase.<br />
<br />
I tried to add it to the page, but my edit was undone.<br />
<br />
See https://bbs.archlinux.org/viewtopic.php?id=236200 .<br />
<br />
[[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 07:53, 16 April 2018 (UTC)<br />
<br />
:Since you were looking specifically for the modesetting driver, surely you have found the notes in [[Xorg#Installation]] and [[Intel_graphics#Installation]]. There is a link to {{man|4|modesetting}} which explains everything. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:53, 16 April 2018 (UTC)<br />
<br />
::Not specifically, nope. I was trying to get a working display, and clearly no one had a clue how to fix it on IRC or on the forum. Hindsight is doesn't sound like a valid solution [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 20:09, 16 April 2018 (UTC)</div>Moviurohttps://wiki.archlinux.org/index.php?title=Talk:Intel_graphics&diff=517651Talk:Intel graphics2018-04-16T07:53:17Z<p>Moviuro: /* Dirver "modesetting" is nowhere to be found */ forgot signature</p>
<hr />
<div>== [drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic update failure on pipe A ==<br />
<br />
Maybe the solution to get rid of the above dmesg log spamming could be mentioned? You just add `options i915 enable_psr=0` to the file `/etc/modprobe.d/i915.conf`. [[User:Bjourne|Bjourne]] ([[User talk:Bjourne|talk]]) 17:04, 19 August 2016 (UTC)<br />
<br />
== Backlight is not adjustable after trying various acpi_osi values ==<br />
<br />
[http://unix.stackexchange.com/q/315178/3645 Full details] on Stack Exchange.<br />
<br />
{{unsigned|20:04, 8 October 2016|L0b0}}<br />
<br />
== DRI3 confusion ==<br />
<br />
I've seen in the forum people ask from time to time how to enable DRI3 on their system.<br />
<br />
As stated many times there, DRI3 should be on for most (if not all) of them. But people keep telling them to check<br />
<br />
cat /var/log/Xorg.0.log | grep DRI<br />
<br />
which shows up this message:<br />
<br />
GLX: Initialized DRI2 GL provider for screen 0<br />
<br />
which is *not accurate*.<br />
<br />
If you run this command instead:<br />
<br />
LC_ALL=C LIBGL_DEBUG=verbose glxinfo | grep DRI<br />
<br />
you might stump with this other message:<br />
<br />
libGL: Using DRI3 for screen 0<br />
<br />
which proves you are using DRI3 even though X11 doesn't reply with the correct information.<br />
<br />
The command was adapted from [https://lists.x.org/archives/xorg-devel/2014-June/042735.html xorg mailing list].<br />
<br />
So, it think adding this information in the page could be of major interest. What do you think?<br />
<br />
[[User:Franzrogar|Franzrogar]] ([[User talk:Franzrogar|talk]]) 07:01, 4 November 2016 (UTC)<br />
<br />
== Guide for screen scaling with external displays via xrandr? ==<br />
<br />
I tried to find instructions for scaling the display resolution without stretching on this wiki page, but the section only says that it's not implemented in the Intel drivers yet. However, [https://unix.stackexchange.com/questions/220387/how-to-set-scaling-mode-for-external-displays-on-intel-gpu this stackexchange thread] has a workaround using an xrandr transform matrix. Should this be added to the wiki page?<br />
<br />
[[User:Ibara|Ibara]] ([[User talk:Ibara|talk]]) 12:35, 22 May 2017 (UTC)<br />
<br />
== Dirver "modesetting" is nowhere to be found ==<br />
<br />
Driver "modesetting" does not appear in the wiki. It would have saved me around 5 hours of pointless mouse-chase.<br />
<br />
I tried to add it to the page, but my edit was undone.<br />
<br />
See https://bbs.archlinux.org/viewtopic.php?id=236200 .<br />
<br />
[[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 07:53, 16 April 2018 (UTC)</div>Moviurohttps://wiki.archlinux.org/index.php?title=Talk:Intel_graphics&diff=517650Talk:Intel graphics2018-04-16T07:52:45Z<p>Moviuro: /* Dirver "modesetting" is nowhere to be found */ new section</p>
<hr />
<div>== [drm:intel_pipe_update_start [i915]] *ERROR* Potential atomic update failure on pipe A ==<br />
<br />
Maybe the solution to get rid of the above dmesg log spamming could be mentioned? You just add `options i915 enable_psr=0` to the file `/etc/modprobe.d/i915.conf`. [[User:Bjourne|Bjourne]] ([[User talk:Bjourne|talk]]) 17:04, 19 August 2016 (UTC)<br />
<br />
== Backlight is not adjustable after trying various acpi_osi values ==<br />
<br />
[http://unix.stackexchange.com/q/315178/3645 Full details] on Stack Exchange.<br />
<br />
{{unsigned|20:04, 8 October 2016|L0b0}}<br />
<br />
== DRI3 confusion ==<br />
<br />
I've seen in the forum people ask from time to time how to enable DRI3 on their system.<br />
<br />
As stated many times there, DRI3 should be on for most (if not all) of them. But people keep telling them to check<br />
<br />
cat /var/log/Xorg.0.log | grep DRI<br />
<br />
which shows up this message:<br />
<br />
GLX: Initialized DRI2 GL provider for screen 0<br />
<br />
which is *not accurate*.<br />
<br />
If you run this command instead:<br />
<br />
LC_ALL=C LIBGL_DEBUG=verbose glxinfo | grep DRI<br />
<br />
you might stump with this other message:<br />
<br />
libGL: Using DRI3 for screen 0<br />
<br />
which proves you are using DRI3 even though X11 doesn't reply with the correct information.<br />
<br />
The command was adapted from [https://lists.x.org/archives/xorg-devel/2014-June/042735.html xorg mailing list].<br />
<br />
So, it think adding this information in the page could be of major interest. What do you think?<br />
<br />
[[User:Franzrogar|Franzrogar]] ([[User talk:Franzrogar|talk]]) 07:01, 4 November 2016 (UTC)<br />
<br />
== Guide for screen scaling with external displays via xrandr? ==<br />
<br />
I tried to find instructions for scaling the display resolution without stretching on this wiki page, but the section only says that it's not implemented in the Intel drivers yet. However, [https://unix.stackexchange.com/questions/220387/how-to-set-scaling-mode-for-external-displays-on-intel-gpu this stackexchange thread] has a workaround using an xrandr transform matrix. Should this be added to the wiki page?<br />
<br />
[[User:Ibara|Ibara]] ([[User talk:Ibara|talk]]) 12:35, 22 May 2017 (UTC)<br />
<br />
== Dirver "modesetting" is nowhere to be found ==<br />
<br />
Driver "modesetting" does not appear in the wiki. It would have saved me around 5 hours of pointless mouse-chase.<br />
<br />
I tried to add it to the page, but my edit was undone.<br />
<br />
See https://bbs.archlinux.org/viewtopic.php?id=236200 .</div>Moviurohttps://wiki.archlinux.org/index.php?title=Intel_graphics&diff=517597Intel graphics2018-04-15T11:47:35Z<p>Moviuro: /* Xorg configuration */ Add "modesetting" as a driver alternative to "intel"</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[cs:Intel graphics]]<br />
[[de:Intel]]<br />
[[es:Intel graphics]]<br />
[[fr:Intel]]<br />
[[hu:Intel graphics]]<br />
[[it:Intel graphics]]<br />
[[ja:Intel Graphics]]<br />
[[pl:Intel graphics]]<br />
[[pt:Intel graphics]]<br />
[[ru:Intel graphics]]<br />
[[zh-hans:Intel graphics]]<br />
[[zh-hant:Intel graphics]]<br />
{{Related articles start}}<br />
{{Related|Intel GMA 3600}}<br />
{{Related|Xorg}}<br />
{{Related|Kernel mode setting}}<br />
{{Related|Xrandr}}<br />
{{Related|Hybrid graphics}}<br />
{{Related|Vulkan}}<br />
{{Related articles end}}<br />
<br />
Since Intel provides and supports open source drivers, Intel graphics are essentially plug-and-play.<br />
<br />
For a comprehensive list of Intel GPU models and corresponding chipsets and CPUs, see [[Wikipedia:Comparison of Intel graphics processing units|this comparison on Wikipedia]].<br />
<br />
{{Note|PowerVR-based graphics ([[Intel GMA 3600|GMA 3600]] series) are not supported by open source drivers.}}<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|mesa}} package, which provides the DRI driver for 3D acceleration.<br />
<br />
* For 32-bit application support, also install the {{Pkg|lib32-mesa}} package from the [[multilib]] repository.<br />
* For the DDX driver (which provides 2D acceleration in [[Xorg]]), [[install]] the {{Pkg|xf86-video-intel}} package. (Often not recommended, see note below.)<br />
* For [[Vulkan]] support (''Ivy Bridge'' and newer), install the {{Pkg|vulkan-intel}} package.<br />
<br />
Also see [[Hardware video acceleration]].<br />
<br />
{{Note|1=Some ([http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Intel-DDX Debian & Ubuntu], [http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Xorg-Intel-DDX-Switch Fedora], [https://community.kde.org/Plasma/5.9_Errata#Intel_GPUs KDE]) recommend not installing the {{Pkg|xf86-video-intel}} driver, and instead falling back on the modesetting driver for fourth generation and newer GPUs. See [https://www.reddit.com/r/archlinux/comments/4cojj9/it_is_probably_time_to_ditch_xf86videointel/], [http://www.phoronix.com/scan.php?page=article&item=intel-modesetting-2017&num=1], [[Xorg#Installation]], and {{man|4|modesetting}}. However, the modesetting driver can cause problems such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 Chromium Issue 370022].}}<br />
<br />
== Loading ==<br />
<br />
The Intel kernel module should load fine automatically on system boot.<br />
<br />
If it does not happen, then:<br />
<br />
* Make sure you do '''not''' have {{ic|nomodeset}} or {{ic|1=vga=}} as a [[kernel parameter]], since Intel requires kernel mode-setting.<br />
* Also, check that you have not disabled Intel by using any modprobe blacklisting within {{ic|/etc/modprobe.d/}} or {{ic|/usr/lib/modprobe.d/}}.<br />
<br />
=== Enable early KMS ===<br />
<br />
[[Kernel mode setting]] (KMS) is supported by Intel chipsets that use the i915 DRM driver and is mandatory and enabled by default.<br />
<br />
Refer to [[Kernel mode setting#Early KMS start]] for instructions on how to enable KMS as soon as possible at the boot process.<br />
<br />
=== Enable GuC / HuC firmware loading ===<br />
<br />
For Skylake and newer processors, some video features (e.g. CBR rate control on SKL low-power encoding mode) may require the use of an updated GPU firmware, which is currently (as of 4.14) not enabled by default. <br />
<br />
It is necessary to add {{ic|1=i915.enable_guc_loading=1 i915.enable_guc_submission=1}} to the [[kernel parameters]] to enable it. Alternatively, if the initramfs already includes the i915 module (see [[Kernel mode setting#Early KMS start]]), you can set these options through a file in {{ic|/etc/modprobe.d/}}. E.g.:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|2=<br />
options i915 enable_guc_loading=1 enable_guc_submission=1<br />
}}<br />
<br />
You can verify that it is enabled by checking ''dmesg'':<br />
<br />
[ 2.142029] [drm] GuC loaded (firmware i915/skl_guc_ver6_1.bin [version 6.1])<br />
<br />
Alternatively, check:<br />
<br />
# cat /sys/kernel/debug/dri/0/i915_huc_load_status<br />
# cat /sys/kernel/debug/dri/0/i915_guc_load_status<br />
<br />
== Xorg configuration ==<br />
<br />
There is no need for any configuration to run [[Xorg]].<br />
<br />
However, to take advantage of some driver options, you will need to create a Xorg configuration file similar to the one below:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel" # If you intend to use xf86-video-intel<br />
# Driver "modesetting"<br />
EndSection}}<br />
<br />
Additional options are added by the user on new lines below {{ic|Driver}}.<br />
<br />
{{Note|<br />
*You may need to indicate {{ic|Option "AccelMethod"}} when creating a configuration file, even just to set it to the default method (currently {{ic|"sna"}}); otherwise, X may crash.<br />
*You might need to add more device sections than the one listed above. This will be indicated where necessary.}} <br />
<br />
For the full list of options, see the {{man|4|intel}} man page.<br />
<br />
== Module-based Powersaving Options ==<br />
<br />
The {{ic|i915}} kernel module allows for configuration via [[Kernel modules#Setting module options|module options]]. Some of the module options impact power saving.<br />
<br />
A list of all options along with short descriptions and default values can be generated with the following command:<br />
<br />
$ modinfo -p i915<br />
<br />
To check which options are currently enabled, run<br />
<br />
# systool -m i915 -av<br />
<br />
You will note that many options default to -1, resulting in per-chip powersaving defaults. It is however possible to configure more aggressive powersaving by using [[Kernel modules#Setting module options|module options]].<br />
<br />
{{Warning|1=Diverting from the defaults will mark the kernel as [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fc9740cebc3ab7c65f3c5f6ce0caf3e4969013ca tainted] from Linux 3.18 onwards. This basically implies using other options than the per-chip defaults is considered experimental and not supported by the developers. }}<br />
<br />
The following set of options should be generally safe to enable:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 enable_rc6=1 enable_fbc=1 semaphores=1<br />
</nowiki>}}<br />
<br />
=== RC6 sleep modes (enable_rc6) ===<br />
<br />
You can experiment with higher values for {{ic|enable_rc6}}, but your GPU may not support them or the activation of the other options [https://wiki.archlinux.org/index.php?title=Talk:Intel_Graphics&oldid=327547#Kernel_Module_options].<br />
<br />
The available {{ic|enable_rc6}} values are a bitmask with bit values RC6=1, RC6p=2, RC6pp=4[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/intel_pm.c#n34] - where "RC6p" and "RC6pp" are lower power states.<br />
<br />
To confirm the current running RC6 level, you can look in sysfs:<br />
<br />
# cat /sys/class/drm/card0/power/rc6_enable<br />
<br />
... if the value read is a lower number than expected, the other RC6 level are probably not supported. Passing {{ic|1=drm.debug=0xe}} will add DRM debugging information to the kernel log - possibly including a line like this:<br />
<br />
[drm:sanitize_rc6_option] Adjusting RC6 mask to 1 (requested 7, valid 1)<br />
<br />
=== Framebuffer compression (enable_fbc) ===<br />
<br />
Framebuffer compression may be unreliable or unavailable on Intel GPU generations before Sandy Bridge (generation 6). This results in messages logged to the system journal similar to this one:<br />
kernel: drm: not enough stolen space for compressed buffer, disabling.<br />
<br />
Enabling frame buffer compression on pre-Sandy Bridge CPUs results in endless error messages:<br />
<br />
$ dmesg |tail <br />
[ 2360.475430] [drm] not enough stolen space for compressed buffer (need 4325376 bytes), disabling<br />
[ 2360.475437] [drm] hint: you may be able to increase stolen memory size in the BIOS to avoid this<br />
<br />
The solution is to disable frame buffer compression which will imperceptibly increase power consumption (around 0.06 W). In order to disable it add {{ic|i915.enable_fbc&#61;0}} to the kernel line parameters. More information on the results of disabled compression can be found [http://kernel.ubuntu.com/~cking/power-benchmarking/background-colour-and-framebuffer-compression/ here].<br />
<br />
== Tips and tricks ==<br />
<br />
=== Tear-free video ===<br />
<br />
The SNA acceleration method causes tearing for some people. To fix this, enable the {{ic|"TearFree"}} option in the driver by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
Option "TearFree" "true"<br />
<br />
See the [https://bugs.freedesktop.org/show_bug.cgi?id=37686 original bug report] for more info.<br />
<br />
{{Note|1=<nowiki></nowiki><br />
* This option may not work when {{ic|SwapbuffersWait}} is {{ic|false}}.<br />
* This option may increases memory allocation considerably and reduce performance. [https://bugs.freedesktop.org/show_bug.cgi?id=37686#c123]<br />
* This option is problematic for applications that are very picky about vsync timing, like [[Wikipedia:Super Meat Boy|Super Meat Boy]].<br />
* This option does not work with UXA acceleration method, only with SNA.<br />
}}<br />
<br />
=== Disable Vertical Synchronization (VSYNC) ===<br />
Useful when:<br />
* Chomium/Chrome has lags and slow performance due to GPU and runs smoothly with --disable-gpu switch<br />
* glxgears test does not show desired performance<br />
<br />
The intel-driver uses [http://www.intel.com/support/graphics/sb/CS-004527.htm Triple Buffering] for vertical synchronization, this allows for full performance and avoids tearing. To turn vertical synchronization off (e.g. for benchmarking) use this {{ic|.drirc}} in your home directory:<br />
<br />
{{hc|~/.drirc|<br />
<device screen&#61;"0" driver&#61;"dri2"><br />
<application name&#61;"Default"><br />
<option name&#61;"vblank_mode" value&#61;"0"/><br />
</application><br />
</device>}}<br />
<br />
{{Warning|Do not use {{Pkg|driconf}} to create this file. It is buggy and will set the wrong driver.}}<br />
<br />
=== Setting scaling mode ===<br />
<br />
This can be useful for some full screen applications:<br />
<br />
$ xrandr --output LVDS1 --set PANEL_FITTING ''param''<br />
<br />
where {{ic|''param''}} can be:<br />
<br />
* {{ic|center}}: resolution will be kept exactly as defined, no scaling will be made,<br />
* {{ic|full}}: scale the resolution so it uses the entire screen or<br />
* {{ic|full_aspect}}: scale the resolution to the maximum possible but keep the aspect ratio.<br />
<br />
If it does not work, try:<br />
<br />
$ xrandr --output LVDS1 --set "scaling mode" ''param''<br />
<br />
where {{ic|''param''}} is one of {{ic|"Full"}}, {{ic|"Center"}} or {{ic|"Full aspect"}}.<br />
<br />
{{Note|1=This option currently does not work for external displays (e.g. VGA, DVI, HDMI, DP). [https://bugs.freedesktop.org/show_bug.cgi?id=90989]}}<br />
<br />
=== KMS Issue: console is limited to small area ===<br />
<br />
One of the low-resolution video ports may be enabled on boot which is causing the terminal to utilize a small area of the screen. To fix, explicitly disable the port with an i915 module setting with {{ic|1=video=SVIDEO-1:d}} in the kernel command line parameter in the bootloader. See [[Kernel parameters]] for more info.<br />
<br />
If that does not work, try disabling TV1 or VGA1 instead of SVIDEO-1. Video port names can be listed with [[xrandr]].<br />
<br />
=== Hardware accelerated H.264 decoding on GMA 4500 ===<br />
<br />
The {{Pkg|libva-intel-driver}} package only provides hardware accelerated MPEG-2 decoding for GMA 4500 series GPUs. The H.264 decoding support is maintained in a separated g45-h264 branch, which can be used by installing {{AUR|libva-intel-driver-g45-h264}} package. Note however that this support is experimental and its development has been abandoned. Using the VA-API with this driver on a GMA 4500 series GPU will offload the CPU but may not result in as smooth a playback as non-accelerated playback. Tests using mplayer showed that using vaapi to play back an H.264 encoded 1080p video halved the CPU load (compared to the XV overlay) but resulted in very choppy playback, while 720p worked reasonably well [https://bbs.archlinux.org/viewtopic.php?id=150550]. This is echoed by other experiences [http://www.emmolution.org/?p=192&cpage=1#comment-12292].<br />
Setting the preallocated video ram size higher in bios results in much better hardware decoded playback. Even 1080p h264 works well if this is done.<br />
Smooth playback (1080p/720p) works also with {{AUR|mpv-git}} in combination with {{AUR|ffmpeg-git}} and {{AUR|libva-intel-driver-g45-h264}}. With MPV and the Firefox plugin "Watch with MPV"[https://addons.mozilla.org/de/firefox/addon/watch-with-mpv/] it is possible to watch hardware accelerated YouTube videos.<br />
<br />
=== Setting brightness and gamma ===<br />
<br />
See [[Backlight]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== SNA issues ===<br />
<br />
''SNA'' is the default acceleration method in {{Pkg|xf86-video-intel}}. If you experience issues with ''SNA'' (e.g. pixelated graphics, corrupt text, etc.), try using ''UXA'' instead, which can be done by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
Option "AccelMethod" "uxa"<br />
<br />
See {{man|4|intel}} under {{ic|Option "AccelMethod"}}.<br />
<br />
=== DRI3 issues ===<br />
<br />
''DRI3'' is the default DRI version in {{Pkg|xf86-video-intel}}. On some systems this can cause issues such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 this]. To switch back to ''DRI2'' add the following line to your [[#Xorg configuration|configuration file]]:<br />
Option "DRI" "2"<br />
<br />
For the {{ic|modesetting}} driver, this method of disabling DRI3 does not work. Instead, one can set the environment variable {{ic|1=LIBGL_DRI3_DISABLE=1}}.<br />
<br />
=== Font and screen corruption in GTK+ applications (missing glyphs after suspend/resume) ===<br />
<br />
Should you experience missing font glyphs in GTK+ applications, the following workaround might help. [[textedit|Edit]] {{ic|/etc/environment}} to add the following line:<br />
<br />
{{hc|/etc/environment|output=<br />
COGL_ATLAS_DEFAULT_BLIT_MODE=framebuffer<br />
}}<br />
<br />
See also [https://bugs.freedesktop.org/show_bug.cgi?id=88584 FreeDesktop bug 88584].<br />
<br />
=== Blank screen during boot, when "Loading modules" ===<br />
<br />
If using "late start" KMS and the screen goes blank when "Loading modules", it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs. See [[Kernel mode setting#Early KMS start]] section.<br />
<br />
Alternatively, appending the following [[kernel parameter]] seems to work as well:<br />
<br />
video=SVIDEO-1:d<br />
<br />
If you need to output to VGA then try this:<br />
<br />
video=VGA-1:1280x800<br />
<br />
=== X freeze/crash with intel driver ===<br />
<br />
Some issues with X crashing, GPU hanging, or problems with X freezing, can be fixed by disabling the GPU usage with the {{ic|NoAccel}} option - add the following lines to your [[#Xorg configuration|configuration file]]:<br />
Option "NoAccel" "True"<br />
<br />
Alternatively, try to disable the 3D acceleration only with the {{ic|DRI}} option:<br />
Option "DRI" "False"<br />
<br />
If you experience crashes and have<br />
<br />
Option "TearFree" "true"<br />
Option "AccelMethod" "sna"<br />
<br />
in your configuration file, in most cases these can be fixed by adding<br />
<br />
i915.semaphores=1<br />
<br />
to your boot parameters.<br />
<br />
=== Baytrail complete freeze ===<br />
<br />
If you are using kernel > 3.16 on Baytrail architecture and randomly encounter total system freezes, the following kernel option is a workaround until [https://bugzilla.kernel.org/show_bug.cgi?id=109051 this bug] is fixed in the linux kernel.<br />
<br />
intel_idle.max_cstate=1<br />
<br />
This is originally an Intel CPU bug that can be triggered by certain c-state transitions. It can also happen with Linux kernel 3.16 or Windows, though apparently much more rarely.<br />
The kernel option will prevent the freeze by avoiding c-state transitions but will also increase power consumption.<br />
<br />
=== Adding undetected resolutions ===<br />
<br />
This issue is covered on the [[Xrandr#Adding undetected resolutions|Xrandr page]].<br />
<br />
=== Weathered colors (color range problem) ===<br />
<br />
Kernel 3.9 [http://lists.freedesktop.org/archives/dri-devel/2013-January/033576.html contains] a new default "Automatic" mode for the "Broadcast RGB" property in the Intel driver. It is almost equivalent to "Limited 16:235" (instead of the old default "Full") whenever an HDMI/DP output is in a [http://raspberrypi.stackexchange.com/questions/7332/what-is-the-difference-between-cea-and-dmt CEA mode]. If a monitor does not support signal in limited color range, it will cause weathered colors.<br />
<br />
{{Note|Some monitors/TVs support both color range. In that case an option often known as ''Black Level'' may need to be adjusted to make them handle the signal correctly. Some TVs can handle signal in limited range only. Setting Broadcast RGB to "Full" will cause color clipping. You may need to set it to "Limited 16:235" manually to avoid the clipping.}}<br />
<br />
One can force mode e.g. {{ic|xrandr --output <HDMI> --set "Broadcast RGB" "Full"}} (replace {{ic|<HDMI>}} with the appropriate output device, verify by running {{ic|xrandr}}).<br />
<br />
Unfortunately, the Intel driver does not support setting the color range through an {{ic|xorg.conf.d}} configuration file.<br />
<br />
A [https://bugzilla.kernel.org/show_bug.cgi?id=94921 bug report] is filed and a patch can be found in the attachment.<br />
<br />
Also there are other related problems which can be fixed editing GPU registers. More information can be found [http://lists.freedesktop.org/archives/intel-gfx/2012-April/016217.html] and [http://github.com/OpenELEC/OpenELEC.tv/commit/09109e9259eb051f34f771929b6a02635806404c].<br />
<br />
=== Backlight is not adjustable===<br />
<br />
If after resuming from suspend, the hotkeys for changing the screen brightness do not take effect, check your configuration against the [[Backlight]] article.<br />
<br />
If the problem persists, try one of the following [[kernel parameters]]:<br />
<br />
acpi_osi=Linux<br />
acpi_osi="!Windows 2012"<br />
acpi_osi=<br />
<br />
=== Corruption/Unresponsiveness in Chromium and Firefox ===<br />
<br />
If you experience corruption, unresponsiveness, lags or slow performance in Chromium and/or Firefox: <br />
* [[#SNA issues|Set the AccelMethod to "uxa"]]<br />
* [[#Disable Vertical Synchronization (VSYNC)|Disable VSYNC]]<br />
<br />
=== Kernel crashing w/kernels 4.0+ on Broadwell/Core-M chips ===<br />
<br />
A few seconds after X/Wayland loads the machine will freeze and journalctl will log a kernel crash referencing the Intel graphics as below:<br />
<br />
Jun 16 17:54:03 hostname kernel: BUG: unable to handle kernel NULL pointer dereference at (null)<br />
Jun 16 17:54:03 hostname kernel: IP: [< (null)>] (null)<br />
...<br />
Jun 16 17:54:03 hostname kernel: CPU: 0 PID: 733 Comm: gnome-shell Tainted: G U O 4.0.5-1-ARCH #1<br />
...<br />
Jun 16 17:54:03 hostname kernel: Call Trace:<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055cc27>] ? i915_gem_object_sync+0xe7/0x190 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0579634>] intel_execlists_submission+0x294/0x4c0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa05539fc>] i915_gem_do_execbuffer.isra.12+0xabc/0x1230 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055d349>] ? i915_gem_object_set_to_cpu_domain+0xa9/0x1f0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ba2ae>] ? __kmalloc+0x2e/0x2a0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555471>] i915_gem_execbuffer2+0x141/0x2b0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa042fcab>] drm_ioctl+0x1db/0x640 [drm]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555330>] ? i915_gem_execbuffer+0x450/0x450 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8122339b>] ? eventfd_ctx_read+0x16b/0x200<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebc36>] do_vfs_ioctl+0x2c6/0x4d0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811f6452>] ? __fget+0x72/0xb0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebec1>] SyS_ioctl+0x81/0xa0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8157a589>] system_call_fastpath+0x12/0x17<br />
Jun 16 17:54:03 hostname kernel: Code: Bad RIP value.<br />
Jun 16 17:54:03 hostname kernel: RIP [< (null)>] (null)<br />
<br />
This can be fixed by disabling execlist support which was changed to default on with kernel 4.0. Add the following [[kernel parameter]]:<br />
i915.enable_execlists=0<br />
<br />
This is known to be broken to at least kernel 4.0.5.<br />
<br />
=== Lag in Windows guests ===<br />
<br />
The video output of a Windows guest in VirtualBox sometimes hangs until the host forces a screen update (e.g. by moving the mouse cursor). Removing the {{ic|1=enable_fbc=1}} option fixes this issue.<br />
<br />
=== Screen flickering ===<br />
<br />
The following power saving features used by intel iGPUs are known to cause flickering in some instances. A temporary solution is to disable one of them using the appropriate [[Kernel_parameters|kernel boot parameter]] option:<br />
<br />
*Rc6 sleep modes (see [[#RC6 sleep modes (enable_rc6)]]), can be disabled with {{ic|1=i915.enable_rc6=0}}.<br />
<br />
*Panel Self Refresh (PSR) {{Bug|49628}} {{Bug|49371}} {{Bug|50605}}. To disable this feature use the option {{ic|1=i915.enable_psr=0}}.<br />
<br />
=== OpenGL 2.1 with i915 driver ===<br />
<br />
The update of {{Pkg|mesa}} from version 13.x to 17 may break support for OpenGL 2.1 on third gen Intel GPUs (GMA3100, see [[wikipedia:List_of_Intel_graphics_processing_units#Third_generation|here]]), as described in this [http://www.phoronix.com/scan.php?page=news_item&px=Mesa-i915-OpenGL-2-Drop article], reverting it back to OpenGL 1.4. However this could be restored manually by setting {{ic|/etc/drirc}} or {{ic|~/.drirc}} options like :<br />
{{hc|/etc/drirc|output=<br />
<driconf><br />
...<br />
<device driver="i915"><br />
<application name="Default"><br />
<option name="'''stub_occlusion_query'''" value="'''true'''" /><br />
<option name="'''fragment_shader'''" value="'''true'''" /><br />
</application><br />
</device><br />
...<br />
</driconf><br />
}}<br />
{{Note|the reason of this step back was Chromium and other apps bad experience. If needed, you might edit the drirc file in a "app-specific" style, see [https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ here], to disable gl2.1 on executable chromium for instance.}}<br />
<br />
== See also ==<br />
<br />
* https://01.org/linuxgraphics/documentation (includes a list of supported hardware)</div>Moviurohttps://wiki.archlinux.org/index.php?title=Steam&diff=516005Steam2018-04-04T16:54:14Z<p>Moviuro: /* Alternative Flatpak installation */ Should now work (copy-paste and don't ask questions)</p>
<hr />
<div>[[Category:Gaming]]<br />
[[ja:Steam]]<br />
[[ru:Steam]]<br />
[[zh-hans:Steam]]<br />
{{Related articles start}}<br />
{{Related|Steam/Troubleshooting}}<br />
{{Related|Steam/Game-specific troubleshooting}}<br />
{{Related|Gaming}}<br />
{{Related|Gamepad}}<br />
{{Related|List of games}}<br />
{{Related articles end}}<br />
[http://store.steampowered.com/about/ Steam] is a popular game distribution platform by Valve.<br />
<br />
Steam for Linux only supports Ubuntu 12.04 LTS and newer [https://support.steampowered.com/kb_article.php?ref&#61;1504-QHXN-8366].<br />
Valve does not offer any support when running into issues with Steam on Arch Linux.<br />
<br />
== Installation ==<br />
<br />
Enable the [[Multilib]] repository and [[install]] the {{Pkg|steam}} package.<br />
<br />
The following requirements must be fulfilled in order to run Steam on Arch Linux:<br />
<br />
* Installed 32-bit version [[Xorg#Driver installation|OpenGL graphics driver]].<br />
* Generated [[Locale#Generating locales|en_US.UTF-8]] locale, preventing invalid pointer error.<br />
* The GUI heavily uses the Arial font. See [[Microsoft fonts]]. An alternative is to use {{Pkg|ttf-liberation}} or [[Steam/Troubleshooting#Text is corrupt or missing|fonts provided by Steam]] instead.<br />
* [[Install]] {{Pkg|wqy-zenhei}} to add support for Asian languages.<br />
<br />
=== SteamCMD ===<br />
<br />
[[Install]] {{AUR|steamcmd}} for the command-line version of the [https://developer.valvesoftware.com/wiki/SteamCMD Steam].<br />
<br />
{{Note|This package installs files under ''root'', so you must run SteamCMD as ''root''.}}<br />
<br />
=== Alternative Flatpak installation ===<br />
<br />
Steam can also be installed with [[Flatpak]] as {{ic|com.valvesoftware.Steam}} from [https://flathub.org/ Flathub]. The easiest way to install it for the current user is by using the Flathub repo and flatpak command:<br />
<br />
flatpak --user remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo<br />
flatpak --user install flathub com.valvesoftware.Steam<br />
flatpak run com.valvesoftware.Steam<br />
<br />
The Flatpak application currently does not support themes. Also you currently can't run games via {{ic|optirun}}/{{ic|primusrun}}, see [https://github.com/flatpak/flatpak/issues/869 Issue#869] for more details.<br />
<br />
The Flatpak application has some [https://www.ctrl.blog/entry/flatpak-steamcloud-xdg known issues with Steam Auto-Cloud] so game progress may not be synced unless you create some symlinks by hand for affected games.<br />
<br />
By default Steam won't be able to access your home directory, you can run the following command to allow it, so that it behaves like on Ubuntu or SteamOS:<br />
<br />
flatpak override com.valvesoftware.Steam --filesystem=$HOME<br />
<br />
== Directory structure ==<br />
<br />
The default Steam install location is {{ic|~/.local/share/Steam}}. If Steam cannot find it, it will prompt you to reinstall it or select the new location. This article uses the {{ic|~/.steam/root}} symlink to refer to the install location.<br />
<br />
=== Library folders ===<br />
<br />
Every Steam application has a unique AppID, which you can find out by looking at its [http://store.steampowered.com/ Steam Store] page path.<br />
<br />
Steam installs games into a directory under {{ic|''LIBRARY''/steamapps/common/}}. {{ic|''LIBRARY''}} normally is <br />
{{ic|~/.steam/root}} but you can also have multiple library folders (''Steam > Settings > Downloads > Steam Library Folders'').<br />
<br />
In order for Steam to recognize a game it needs to have an<br />
{{ic|appmanifest_''AppId''.acf}} file in {{ic|''LIBRARY''/steamapps/}}. The appmanifest file uses the <br />
[https://developer.valvesoftware.com/wiki/KeyValues KeyValues] format and its {{ic|installdir}} property<br />
determines the game directory name.<br />
<br />
== Usage ==<br />
<br />
steam [ -options ] [ steam:// URL ]<br />
<br />
For the available command-line options see the [https://developer.valvesoftware.com/wiki/Command_Line_Options#Steam_.28Windows.29 Command Line Options article on the Valve Developer Wiki].<br />
<br />
Steam also accepts an optional Steam URL, see the [https://developer.valvesoftware.com/wiki/Steam_browser_protocol Steam browser procotol].<br />
<br />
== Launch options ==<br />
<br />
When you launch a Steam game, Steam executes its '''launch command''' in a [[Bash]] shell.<br />
To let you alter the launch command Steam provides '''launch options''',<br />
which can be set for a game by right-clicking on it in your library, selecting Properties and clicking on ''Set Launch Options''.<br />
<br />
By default Steam simply appends your option string to the launch command. To set environment variables or<br />
pass the launch command as an argument to another command you can use the {{ic|%command%}} substitute.<br />
<br />
=== Examples ===<br />
<br />
* only arguments: {{ic|-foo}}<br />
* environment variables: {{ic|1=FOO=bar BAZ=bar %command% -baz}}<br />
* completely different command: {{ic|othercommand # %command%}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Big Picture Mode without a window manager ===<br />
<br />
To start Steam in Big Picture Mode from a [[Display manager]], create a {{ic|/usr/share/xsessions/steam-big-picture.desktop}} file with the following contents: <br />
<br />
{{hc|/usr/share/xsessions/steam-big-picture.desktop|<nowiki><br />
[Desktop Entry]<br />
Name=Steam Big Picture Mode<br />
Comment=Start Steam in Big Picture Mode<br />
Exec=/usr/bin/steam -bigpicture<br />
TryExec=/usr/bin/steam<br />
Icon=<br />
Type=Application</nowiki>}}<br />
<br />
=== Steam skins ===<br />
<br />
The Steam interface can be customized using skins. Skins can overwrite interface-specific files in {{ic|~/.steam/root}}.<br />
<br />
To install a skin:<br />
<br />
# Place its directory in {{ic|~/.steam/root/skins}}.<br />
# Open ''Steam > Settings > Interface'' and select it.<br />
# Restart Steam.<br />
<br />
An extensive list of skins can be found in [http://forums.steampowered.com/forums/showthread.php?t=1161035 this Steam forums post].<br />
<br />
{{Note|Using an outdated skin may cause visual errors.}}<br />
<br />
==== Creating skins ====<br />
<br />
Nearly all Steam styles are defined in {{ic|~/.steam/root/resource/styles/steam.styles}} (the file is over 3,500 lines long). For a skin to be recognized it needs its own {{ic|resource/styles/steam.styles}}.<br />
When a Steam update changes the official {{ic|steam.styles}} your skin may become outdated, potentially resulting in visual errors.<br />
<br />
See {{ic|~/.steam/root/skins/skins_readme.txt}} for a primer on how to create skins.<br />
<br />
=== Changing the Steam notification position ===<br />
<br />
The default Steam notification position is bottom right.<br />
<br />
You can change the Steam notification position by altering {{ic|Notifications.PanelPosition}} in<br />
<br />
* {{ic|resource/styles/steam.styles}} for desktop notifications, and<br />
* {{ic|resource/styles/gameoverlay.styles}} for in-game notifications<br />
<br />
Both files are overwritten by Steam on startup and {{ic|steam.styles}} is only read on startup.<br />
<br />
{{Note|Some games do not respect the setting in {{ic|gameoverlay.styles}} e.g. XCOM: Enemy Unknown.}}<br />
<br />
==== Use a skin ====<br />
<br />
You can create a skin to change the notification position to your liking. For example to change the position to top right:<br />
<br />
$ cd ~/.steam/root/skins<br />
$ mkdir -p Top-Right/resource<br />
$ cp -r ~/.steam/root/resource/styles Top-Right/resource<br />
$ sed -i '/Notifications.PanelPosition/ s/"[A-Za-z]*"/"TopRight"/' Top-Right/resource/styles/*<br />
<br />
==== Live patching ====<br />
<br />
{{ic|gameoverlay.styles}} can be overwritten while Steam is running, allowing you to have game-specific notification positions.<br />
<br />
{{hc|~/.steam/notifpos.sh|<br />
sed -i "/Notifications.PanelPosition/ s/\"[A-Za-z]*\"/\"$1\"/" ~/.steam/root/resource/styles/gameoverlay.styles<br />
}}<br />
<br />
And the [[#Launch options]] should be something like:<br />
<br />
~/.steam/notifpos.sh TopLeft && %command%<br />
<br />
=== In-home streaming ===<br />
<br />
Steam has built-in support for [http://store.steampowered.com/streaming/ in-home streaming].<br />
<br />
See [https://steamcommunity.com/sharedfiles/filedetails/?id=680514371 this Steam Community guide] on how to setup a headless in-home streaming server on Linux.<br />
<br />
== Troubleshooting ==<br />
<br />
See [[Steam/Troubleshooting]].<br />
<br />
== See also ==<br />
<br />
* [https://wiki.gentoo.org/wiki/Steam Gentoo Wiki article]<br />
* [https://pcgamingwiki.com/wiki/The_Big_List_of_DRM-Free_Games_on_Steam The Big List of DRM-Free Games on Steam] at PCGamingWiki<br />
* [http://steam.wikia.com/wiki/List_of_DRM-free_games List of DRM-free games] at Wikia<br />
* [http://store.steampowered.com/browse/linux Steam Linux store]</div>Moviurohttps://wiki.archlinux.org/index.php?title=Keybase&diff=510562Keybase2018-02-12T17:11:45Z<p>Moviuro: /* Signup / Login */ service file missing; add workaround</p>
<hr />
<div>[[Category:Encryption]]<br />
[[ja:Keybase]]<br />
{{Related articles start}}<br />
{{Related|GnuPG}}<br />
{{Related articles end}}<br />
<br />
From [[Wikipedia:Keybase|Wikipedia]]:<br />
:Keybase is a key directory that maps social media identities to encryption keys (including, but not limited to PGP keys) in a publicly auditable manner. Keybase also offers an encrypted chat and cloud storage system, called Keybase Chat and the Keybase filesystem respectively. Files placed in the public portion of the filesystem are served from a public endpoint, as well as locally from a filesystem mounted by the Keybase client. Keybase supports publicly connecting Twitter, GitHub, Facebook, Reddit, and Hacker News identities to encryption keys, along with Bitcoin and Zcash wallet addresses.<br />
<br />
== Installation ==<br />
<br />
Keybase is provided by the {{Pkg|keybase}} package, however this does not yet include the GUI or the KBFS filesystem. If you want the GUI and KBFS filesystem install {{AUR|keybase-bin}}.<br />
<br />
After installing or updating, run:<br />
<br />
$ run_keybase<br />
<br />
== Signup / Login ==<br />
<br />
{{Note|The signup and login commands will fail with keybase-1.0.41 because the `keybase.service` does not ship with the package (see [https://bugs.archlinux.org/task/56831 #56831]). Run the following command in another terminal:<br />
<br />
$ keybase service<br />
<br />
}}<br />
<br />
To signup for a Keybase account use, and follow the on-screen prompts:<br />
<br />
$ keybase signup<br />
<br />
If you already have a Keybase account you can login with:<br />
<br />
$ keybase login <keybase_username><br />
<br />
== GnuPG Keys ==<br />
<br />
During the interactive signup if you already have any GnuPG key pairs on your keyring, Keybase will ask if you wish to use one of them. If you do not have a key pair, you can generate one with:<br />
<br />
$ keybase gpg gen<br />
<br />
This will interactively generate a key pair and securely upload the keys.<br />
<br />
== Keybase Filesystem (KBFS) ==<br />
<br />
KBFS uses [[Wikipedia:Filesystem in Userspace|FUSE]] to mount the remote cryptographic filesystem via the [[systemd]] unit {{ic|keybase.mount}}.<br />
<br />
Keybase allows users to store up to 10 GB of files in a cloud storage called the Keybase filesystem. The filesystem is divided into three parts: public files, private files, and team files. The filesystem is mounted to {{ic|/keybase}}.<br />
<br />
All files under {{ic|/keybase/public}} are automatically signed by the client. All files under {{ic|/keybase/private}} are both encrypted and signed before being uploaded, making them end-to-end encrypted.<br />
<br />
== See also ==<br />
<br />
* [https://keybase.io/ Keybase Homepage]<br />
* [[Wikipedia:Keybase]]<br />
* [https://keybase.io/docs/command_line Keybase Basics]</div>Moviurohttps://wiki.archlinux.org/index.php?title=Tmux&diff=437242Tmux2016-06-04T10:14:17Z<p>Moviuro: /* Autostart with systemd */ We can now do this without disturbing root</p>
<hr />
<div>[[Category:Terminal emulators]]<br />
[[es:Tmux]]<br />
[[ja:Tmux]]<br />
[[ru:Tmux]]<br />
[[tr:Tmux]]<br />
[[zh-CN:Tmux]]<br />
{{Related articles start}}<br />
{{Related|GNU Screen}}<br />
{{Related articles end}}<br />
<br />
[http://tmux.github.io/ Tmux] is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." <br />
<br />
Tmux is a BSD-licensed alternative to [[GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [https://raw.githubusercontent.com/tmux/tmux/master/FAQ tmux FAQ page].<br />
<br />
== Installation ==<br />
[[Install]] the {{Pkg|tmux}} package.<br />
<br />
== Configuration ==<br />
A user-specific configuration file should be located at {{ic|~/.tmux.conf}}, while a global configuration file should be located at {{ic|/etc/tmux.conf}}. Default configuration files can be found in {{Ic|/usr/share/tmux/}}. <br />
<br />
=== Key bindings ===<br />
<br />
By default, command key bindings are prefixed by {{Ic|Ctrl-b}}. For example, to vertically split a window type {{Ic|Ctrl-b+%}}.<br />
<br />
After splitting a window into multiple panes, a pane can be resized by the hitting prefix key (e.g. {{Ic|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic [[screen]] key bindings copy {{ic|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{ic|tmux.conf}}. For example, the default prefix binding of {{Ic|Ctrl-b}} can be changed to {{Ic|Ctrl-a}} by adding the following commands in your configuration file:<br />
<br />
{{bc|<br />
unbind C-b<br />
set -g prefix C-a<br />
bind C-a send-prefix<br />
}}<br />
<br />
{{Tip|Quote special characters to use them as prefix. You may also use {{ic|Alt}} (called Meta) instead of {{ic|Ctrl}}. For example: {{ic|set -g prefix m-'\'}}}}<br />
<br />
Additional ways to move between windows include the following:<br />
<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
Tmux has a find-window option & key binding to ease navigation of many windows:<br />
<br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
==== Copy Mode ====<br />
<br />
A tmux window may be in one of several modes. The default permits direct access to the terminal attached to the window; the other is copy mode. Once in copy mode you can navigate the buffer including scrolling the history. Use vi or emacs-style key bindings in copy mode. The default is emacs, unless VISUAL or EDITOR contains ‘vi’<br />
<br />
To enter copy mode do the following:<br />
<br />
Ctrl-b [<br />
<br />
You can navigate the buffer as you would in your default editor.<br />
<br />
To quit copy mode, use one of the following keybindings:<br />
<br />
vi mode:<br />
q<br />
emacs mode:<br />
Esc<br />
<br />
=== Browsing URLs ===<br />
To browse URLs inside tmux you must have {{AUR|urlview}} installed and configured.<br />
<br />
Inside a new terminal:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e urlview /tmp/tmux-buffer"<br />
<br />
Or inside a new tmux window (no new terminal needed):<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; new-window -n "urlview" '$SHELL -c "urlview < /tmp/tmux-buffer"'<br />
<br />
=== Setting the correct term ===<br />
==== 256 colors ====<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in {{ic|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or:<br />
<br />
set -g default-terminal "xterm-256color"<br />
<br />
Also, if tmux messes up, you can force tmux to assume that the terminal support 256 colors, by adding this in your .bashrc:<br />
<br />
alias tmux="tmux -2"<br />
<br />
==== 24-bit color ====<br />
Tmux supports 24-bit color as of version 2.2 ([https://github.com/tmux/tmux/commit/427b8204268af5548d09b830e101c59daa095df9]). If your terminal supports 24-bit color (see this [https://gist.github.com/XVilka/8346728 gist]), add your terminal to the {{ic|terminal-overrides}} setting. For example, if you use [[Termite]], you would add:<br />
<br />
set -ga terminal-overrides ",xterm-termite:Tc"<br />
<br />
See the tmux(1) man page for details about the {{ic|Tc}} terminfo extension.<br />
<br />
==== xterm-keys ====<br />
To enable xterm-keys in your {{ic|tmux.conf}}, you have to add the following line<br />
<br />
set-option -g xterm-keys on<br />
<br />
If you enable xterm-keys in your {{ic|tmux.conf}}, then you need to build a custom terminfo to declare the new escape codes or applications will not know about them. Compile the following with {{ic|tic}} and you can use "xterm-screen-256color" as your TERM:<br />
<br />
# A screen- based TERMINFO that declares the escape sequences<br />
# enabled by the tmux config "set-window-option -g xterm-keys".<br />
#<br />
# Prefix the name with xterm- since some applications inspect<br />
# the TERM *name* in addition to the terminal capabilities advertised.<br />
xterm-screen-256color|GNU Screen with 256 colors bce and tmux xterm-keys,<br />
<br />
# As of Nov'11, the below keys are picked up by<br />
# .../tmux/blob/master/trunk/xterm-keys.c:<br />
kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,<br />
kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~,<br />
kRIT=\E[1;2C,<br />
<br />
# Change this to screen-256color if the terminal you run tmux in<br />
# doesn't support bce:<br />
use=screen-256color-bce,<br />
<br />
=== Other Settings ===<br />
To limit the scrollback buffer to 10000 lines:<br />
set -g history-limit 10000<br />
<br />
Terminal emulator settings can be overridden with<br />
set -ga terminal-overrides ',xterm*:smcup@:rmcup@'<br />
set -ga terminal-override ',rxvt-uni*:XT:Ms=\E]52;%p1%s;%p2%s\007'<br />
<br />
Mouse can be toggled with<br />
bind-key m set-option -g mouse on \; display 'Mouse: ON'<br />
bind-key M set-option -g mouse off \; display 'Mouse: OFF'<br />
<br />
=== Autostart with systemd ===<br />
There are some notable advantages to starting a tmux server at startup.<br />
Notably, when you start a new tmux session, having the service already running reduces any delays in the startup.<br />
<br />
Furthermore, any customization attached to your tmux session will be retained and your tmux session can be made to persist even if you have never logged in, if you have some reason to do that (like a heavily scripted tmux configuration or shared user tmux sessions).<br />
<br />
==== As user ====<br />
The service below starts ''tmux'' as user.<br />
<br />
{{hc|/etc/systemd/user/tmux.service|<nowiki><br />
[Unit]<br />
Description=Start tmux in detached session<br />
<br />
[Service]<br />
Type=forking<br />
ExecStart=/usr/bin/tmux new-session -s %u -d<br />
ExecStop=/usr/bin/tmux kill-session -t %u<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki>}}<br />
<br />
To enable it, you need to enable linger for your user:<br />
<br />
$ loginctl enable-linger<br />
$ systemctl --user enable tmux<br />
<br />
Alternatively, you can place this file within your [[systemd/User]] directory, for example {{ic|~/.config/systemd/user/tmux.service}}.<br />
<br />
==== With help from root user ====<br />
The service below starts ''tmux'' for the specified user (i.e. start with {{ic|tmux@''username''.service}}):<br />
<br />
{{hc|/etc/systemd/system/tmux@.service|<nowiki><br />
[Unit]<br />
Description=Start tmux in detached session<br />
<br />
[Service]<br />
Type=forking<br />
User=%I<br />
ExecStart=/usr/bin/tmux new-session -s %u -d<br />
ExecStop=/usr/bin/tmux kill-session -t %u<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
{{Tip|You may want to add {{ic|1=WorkingDirectory=''custom_path''}} to customize working directory.}}<br />
<br />
== Session initialization ==<br />
You can have tmux open a session with preloaded windows by including those details in your {{ic|~/.tmux.conf}}:<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{ic|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
== Troubleshooting ==<br />
<br />
=== Scrolling issues ===<br />
<br />
If you have issues scrolling with Shift-Page Up/Down in your terminal, the following will remove the smcup and rmcup capabilities for any term that reports itself as anything beginning with {{ic|xterm}}:<br />
<br />
set -ga terminal-overrides ',xterm*:smcup@:rmcup@'<br />
<br />
This tricks the terminal emulator into thinking Tmux is a full screen application like pico or mutt[http://superuser.com/questions/310251/use-terminal-scrollbar-with-tmux], which will make the scrollback be recorded properly. Beware however, it will get a bit messed up when switching between windows/panes. Consider using Tmux's native scrollback instead.<br />
<br />
=== Mouse scrolling ===<br />
<br />
{{Note|This interferes with selection buffer copying and pasting. To copy/paste to/from the selection buffer hold the shift key.}}<br />
<br />
If you want to scroll with your mouse wheel, ensure mode-mouse is on in .tmux.conf<br />
set -g mouse on<br />
<br />
You can set scroll History with:<br />
set -g history-limit 30000<br />
<br />
For mouse wheel scrolling as from tmux 2.1 try adding one or both of these to ~/.tmux.conf<br />
bind -T root WheelUpPane if-shell -F -t = "#{alternate_on}" "send-keys -M" "select-pane -t =; copy-mode -e; send-keys -M"<br />
bind -T root WheelDownPane if-shell -F -t = "#{alternate_on}" "send-keys -M" "select-pane -t =; send-keys -M"<br />
<br />
Though the above will only scroll one line at a time, add this solution to scroll an entire page instead<br />
bind -t vi-copy WheelUpPane page-up<br />
bind -t vi-copy WheelDownPane page-down<br />
bind -t emacs-copy WheelUpPane page-up<br />
bind -t emacs-copy WheelDownPane page-down<br />
<br />
=== Terminal emulator does not support UTF-8 mouse events ===<br />
<br />
When the terminal emulator does not support the UTF-8 mouse events and the {{ic|mouse on}} tmux option is set, left-clicking inside the terminal window might paste strings like {{ic|[M#}} or {{ic|[Ma}} into the promt.<br />
<br />
To solve this issue set:<br />
<br />
set -g mouse-utf8 off<br />
<br />
=== Fix reverse-video/italic mode in urxvt ===<br />
<br />
If your reverse-video and italic modes are reversed, for example in vim when italics are replaced by highlighting, or in less when the search highlighting is replaced by italics. This is because the screen terminfo doesn't define italics, and the italics escape of urxvt happens to be the standout escape defined in the terminfo. <br />
<br />
This could be fixed by use the tmux or tmux-256color terminfo by putting the following line in your tmux.conf: <br />
set -g default-terminal "tmux-256color"<br />
<br />
=== Shift+F6 not working in Midnight Commander ===<br />
<br />
See [[Midnight Commander#Shift+F6 not working]].<br />
<br />
== X clipboard integration ==<br />
<br />
{{Tip|The tmux plugin [https://github.com/tmux-plugins/tmux-yank tmux-yank] provides similar functionality.}}<br />
<br />
It is possible to copy tmux selection to X clipboard (and to X primary/secondary selection) and in reverse direction. The following tmux config file snippet effectively integrates X clipboard/selection with the current tmux selection using the program {{Pkg|xsel}}:<br />
<br />
# Emacs style<br />
bind-key -t emacs-copy M-w copy-pipe "xsel -i -p -b"<br />
bind-key C-y run "xsel -o | tmux load-buffer - ; tmux paste-buffer"<br />
<br />
# Vim style<br />
bind-key -t vi-copy y copy-pipe "xsel -i -p -b"<br />
bind-key p run "xsel -o | tmux load-buffer - ; tmux paste-buffer"<br />
<br />
{{pkg|xclip}} could also be used for that purpose, unlike xsel it works better on printing raw bitstream that doesn't fit the current locale. Nevertheless, it is neater to use <code>xsel</code> instead of <code>xclip</code>, because xclip does not close STDOUT after it has read from tmux's buffer. As such, tmux doesn't know that the copy task has completed, and continues to wait for xclip's termination, thereby rendering tmux unresponsive. A workaround is to redirect <code>STDOUT</code> of <code>xclip</code> to <code>/dev/null</code>, like in the following:<br />
<br />
# Vim style<br />
bind-key -t vi-copy y copy-pipe "xclip -i -sel clip > /dev/null"<br />
bind-key p run "xclip -o -sel clip | tmux load-buffer -"<br />
<br />
=== Urxvt middle click ===<br />
<br />
{{Note|To use this, you need to enable mouse support}}<br />
<br />
There is an unofficial perl extension (mentioned in the official [http://sourceforge.net/p/tmux/tmux-code/ci/master/tree/FAQ FAQ]) to enable copying/pasting in and out of urxvt with tmux via Middle Mouse Clicking.<br />
<br />
First, you will need to download the perl script and place it into urxvts perl lib:<br />
<br />
{{bc|wget http://anti.teamidiot.de/static/nei/*/Code/urxvt/osc-xterm-clipboard<br />
mv osc-xterm-clipboard /usr/lib/urxvt/perl/|<br />
}}<br />
<br />
You will also need to enable that perl script in your .Xdefaults:<br />
<br />
{{hc|~/.Xdefaults|<br />
...<br />
*URxvt.perl-ext-common: osc-xterm-clipboard<br />
...<br />
}}<br />
<br />
Next, you want to tell tmux about the new function and enable mouse support (if you haven't already):<br />
<br />
{{hc|~/.tmux.conf|<br />
...<br />
set-option -ga terminal-override ',rxvt-uni*:XT:Ms<nowiki>=</nowiki>\E]52;%p1%s;%p2%s\007'<br />
set -g mouse on<br />
...<br />
}}<br />
<br />
That's it. Be sure to end all instances of tmux before trying the new MiddleClick functionality.<br />
<br />
While in tmux, Shift+MiddleMouseClick will paste the clipboard selection while just MiddleMouseClick will paste your tmux buffer.<br />
Outside of tmux, just use MiddleMouseClick to paste your tmux buffer and your standard Ctrl-c to copy.<br />
<br />
== Tips and tricks ==<br />
=== Start tmux with default session layout ===<br />
To setup your default Tmux session layout, you install {{AUR|tmuxinator}} from [[AUR]]. Test your installation with<br />
<br />
tmuxinator doctor<br />
<br />
==== Get the default layout values ====<br />
Start Tmux as usual and configure your windows and panes layout as you like. When finished, get the current layout values by executing (while you are still within the current Tmux session)<br />
<br />
tmux list-windows<br />
<br />
The output may look like this (two windows with 3 panes and 2 panes layout)<br />
<br />
0: default* (3 panes) [274x83] [layout 20a0,274x83,0,0{137x83,0,0,3,136x83,138,0[136x41,138,0,5,136x41,138,42,6]}] @2 (active)<br />
1: remote- (2 panes) [274x83] [layout e3d3,274x83,0,0[274x41,0,0,4,274x41,0,42,7]] @3 <br />
<br />
The Interesting part you need to copy for later use begins after '''[layout...''' and excludes '''... ] @2 (active)'''. For the first window layout you need to copy e.g. '''20a0,274x83,0,0{137x83,0,0,3,136x83,138,0[136x41,138,0,5,136x41,138,42,6]}'''<br />
<br />
==== Define the default tmux layout ====<br />
<br />
Knowing this, you can exit the current tmux session. Following this, you create your default Tmux session layout by editing Tmuxinator's config file (Don't copy the example, get your layout values as described above)<br />
<br />
{{hc|~/.tmuxinator/default.yml|<nowiki><br />
name: default<br />
root: ~/<br />
windows:<br />
- default:<br />
layout: 20a0,274x83,0,0{137x83,0,0,3,136x83,138,0[136x41,138,0,5,136x41,138,42,6]}<br />
panes:<br />
- clear<br />
- vim<br />
- clear && emacs -nw<br />
- remote:<br />
layout: 24ab,274x83,0,0{137x83,0,0,3,136x83,138,0,4}<br />
panes:<br />
- <br />
- <br />
</nowiki>}}<br />
<br />
The example defines two windows named "default" and "remote". With your determined layout values. For each pane you have to use at least one {{ic|-}} line. Within the first window panes you start the commandline "clear" in pane one, "vim" in pane two and "clear && emacs -nw" executes two commands in pane three on each Tmux start. The second window layout has two panes without defining any start commmands.<br />
<br />
Test the new default layout with (yes, it is "mux"):<br />
<br />
mux default<br />
<br />
==== Autostart tmux with default tmux layout ====<br />
<br />
If you like to start your terminal session with your default Tmux session layout edit<br />
{{hc|~/.bashrc|<nowiki><br />
if [ -z "$TMUX" ]; then<br />
mux default <br />
fi <br />
</nowiki>}}<br />
<br />
====Alternate approach for default session====<br />
Instead of using the above method, one can just write a bash script that when run, will create the default session and attach to it.<br />
Then you can execute it from a terminal to get the pre-designed configuration in that terminal<br />
<br />
#!/bin/bash<br />
tmux new-session -d -n WindowName Command<br />
tmux new-window -n NewWindowName<br />
tmux split-window -v<br />
tmux selectp -t 1<br />
tmux split-window -h<br />
tmux selectw -t 1<br />
tmux -2 attach-session -d<br />
<br />
===Start tmux in urxvt===<br />
Use this command to start urxvt with a started tmux session. I use this with the exec command from my .ratpoisonrc file.<br />
{{bc|<nowiki>urxvt -e bash -c "tmux -q has-session && exec tmux attach-session -d || exec tmux new-session -n$USER -s$USER@$HOSTNAME"</nowiki>}}<br />
<br />
=== Start tmux on every shell login ===<br />
<br />
==== Bash ====<br />
<br />
For bash, simply add the following line of bash code to your .bashrc before your aliases; the code for other shells is very similar:<br />
<br />
{{hc|~/.bashrc|<nowiki><br />
# If not running interactively, do not do anything<br />
[[ $- != *i* ]] && return<br />
[[ -z "$TMUX" ]] && exec tmux<br />
</nowiki>}}<br />
<br />
{{note|This snippet ensures that tmux is not launched inside of itself (something tmux usually already checks for anyway). tmux sets $TMUX to the socket it is using whenever it runs, so if $TMUX isn't set or is length 0, we know we aren't already running tmux.}}<br />
<br />
Add the following snippet to start only one session (unless you start some manually), on login, try attach at first, only create a session if no tmux is running.<br />
<br />
{{bc|<nowiki><br />
# TMUX<br />
if which tmux >/dev/null 2>&1; then<br />
#if not inside a tmux session, and if no session is started, start a new session<br />
test -z "$TMUX" && (tmux attach || tmux new-session)<br />
fi<br />
</nowiki>}}<br />
<br />
The following snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
{{bc|<nowiki><br />
# TMUX<br />
if which tmux >/dev/null 2>&1; then<br />
# if no session is started, start a new session<br />
test -z ${TMUX} && tmux<br />
<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
</nowiki>}}<br />
<br />
Another possibility is to try to attach to existing deattached session or start a new session:<br />
<br />
{{bc|<nowiki><br />
if [[ -z "$TMUX" ]] ;then<br />
ID="`tmux ls | grep -vm1 attached | cut -d: -f1`" # get the id of a deattached session<br />
if [[ -z "$ID" ]] ;then # if not available create a new one<br />
tmux new-session<br />
else<br />
tmux attach-session -t "$ID" # if available attach to it<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
==== Fish ====<br />
<br />
{{Move|Fish}}<br />
<br />
To start tmux on every shell login with fish, use the following:<br />
<br />
{{hc|~/.config/fish/config.fish|<nowiki><br />
# If not running interactively, do not do anything<br />
if status --is-interactive<br />
if test -z (echo $TMUX)<br />
tmux<br />
end<br />
end<br />
</nowiki>}}<br />
<br />
Alternatively, to start only one tmux session, or try to attach to another session on launch:<br />
{{hc|~/.config/fish/config.fish|<nowiki><br />
if status --is-interactive<br />
if test -z (echo $TMUX)<br />
if not test (tmux attach)<br />
tmux new-session<br />
end<br />
end<br />
end<br />
</nowiki>}}<br />
<br />
{{note|Instead of using the shell config file, you can launch tmux when you start your terminal emulator. (i. e. urxvt -e tmux)}}<br />
<br />
=== Start a non-login shell ===<br />
<br />
Tmux starts a [http://unix.stackexchange.com/questions/38175 login shell] [http://comments.gmane.org/gmane.comp.terminal-emulators.tmux.user/5997 by default], which may result in multiple negative side effects:<br />
<br />
* Users of [[Wikipedia:fortune (Unix)|fortune]] may notice that quotes are printed when creating a new panel.<br />
* The configuration files for login shells such as {{ic|~/.profile}} are interpreted each time a new panel is created, so commands intended to be run on session initialization (e.g. setting audio level) are executed.<br />
<br />
To disable this behaviour, add to {{ic|~/.tmux.conf}}:<br />
<br />
set -g default-command "${SHELL}"<br />
<br />
=== Use tmux windows like tabs ===<br />
<br />
The following settings added to {{ic|~/.tmux.conf}} allow to use tmux windows like tabs, such as those provided by the reference of these hotkeys — [[rxvt-unicode#urxvtq_with_tabbing|urxvt's tabbing extensions]]. An advantage thereof is that these virtual “tabs” are independent of the terminal emulator.<br />
<br />
#urxvt tab like window switching (-n: no prior escape seq)<br />
bind -n S-down new-window<br />
bind -n S-left prev<br />
bind -n S-right next<br />
bind -n C-left swap-window -t -1<br />
bind -n C-right swap-window -t +1<br />
<br />
Of course, those should not overlap with other applications' hotkeys, such as the terminal's. Given that they substitute terminal tabbing that might as well be deactivated, though.<br />
<br />
It can also come handy to supplement the EOT hotkey {{ic|Ctrl+d}} with one for tmux's detach:<br />
<br />
bind-key -n C-j detach<br />
<br />
=== Clients simultaneously interacting with various windows of a session ===<br />
<br />
In [http://mutelight.org/articles/practical-tmux Practical Tmux], Brandur Leach writes:<br />
<br />
: Screen and tmux's behaviour for when multiple clients are attached to one session differs slightly. In Screen, each client can be connected to the session but view different windows within it, but in tmux, all clients connected to one session must view the same window.<br />
: This problem can be solved in tmux by spawning two separate sessions and synchronizing the second one to the windows of the first, then pointing a second new session to the first.<br />
<br />
The script “{{Ic|tmx}}” below implements this — the version here is slightly modified to execute “{{Ic|tmux new-window}}” if “1” is its second parameter. Invoked as {{Ic|tmx <base session name> [1]}} it launches the base session if necessary. Otherwise a new “client” session linked to the base, optionally add a new window and attach, setting it to kill itself once it turns “zombie”.<br />
<br />
{{hc|tmx|2=<nowiki><br />
#!/bin/bash<br />
<br />
#<br />
# Modified TMUX start script from:<br />
# http://forums.gentoo.org/viewtopic-t-836006-start-0.html<br />
#<br />
# Store it to `~/bin/tmx` and issue `chmod +x`.<br />
#<br />
<br />
# Works because bash automatically trims by assigning to variables and by <br />
# passing arguments<br />
trim() { echo $1; }<br />
<br />
if [[ -z "$1" ]]; then<br />
echo "Specify session name as the first argument"<br />
exit<br />
fi<br />
<br />
# Only because I often issue `ls` to this script by accident<br />
if [[ "$1" == "ls" ]]; then<br />
tmux ls<br />
exit<br />
fi<br />
<br />
base_session="$1"<br />
# This actually works without the trim() on all systems except OSX<br />
tmux_nb=$(trim `tmux ls | grep "^$base_session" | wc -l`)<br />
if [[ "$tmux_nb" == "0" ]]; then<br />
echo "Launching tmux base session $base_session ..."<br />
tmux new-session -s $base_session<br />
else<br />
# Make sure we are not already in a tmux session<br />
if [[ -z "$TMUX" ]]; then<br />
echo "Launching copy of base session $base_session ..."<br />
# Session id is date and time to prevent conflict<br />
session_id=`date +%Y%m%d%H%M%S`<br />
# Create a new session (without attaching it) and link to base session <br />
# to share windows<br />
tmux new-session -d -t $base_session -s $session_id<br />
if [[ "$2" == "1" ]]; then<br />
# Create a new window in that session<br />
tmux new-window<br />
fi<br />
# Attach to the new session & kill it once orphaned<br />
tmux attach-session -t $session_id \; set-option destroy-unattached<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
A useful setting for this is<br />
<br />
setw -g aggressive-resize on<br />
<br />
added to {{ic|~/.tmux.conf}}. It causes tmux to resize a window based on the smallest client actually viewing it, not on the smallest one attached to the entire session.<br />
<br />
An alternative taken from [http://comments.gmane.org/gmane.comp.terminal-emulators.tmux.user/2632] is to put the following ~/.bashrc:<br />
<br />
{{hc|.bashrc|2=<nowiki><br />
function rsc() {<br />
CLIENTID=$1.`date +%S`<br />
tmux new-session -d -t $1 -s $CLIENTID \; set-option destroy-unattached \; attach-session -t $CLIENTID<br />
}<br />
<br />
function mksc() {<br />
tmux new-session -d -s $1<br />
rsc $1<br />
}<br />
</nowiki>}}<br />
<br />
Citing the author:<br />
<br />
: "mksc foo" creates a always detached permanent client named "foo". It also calls "rsc foo" to create a client to newly created session. "rsc foo" creates a new client grouped by "foo" name. It has destroy-unattached turned on so when I leave it, it kills client.<br />
: Therefore, when my computer looses network connectivity, all "foo.something" clients are killed while "foo" remains. I can then call "rsc foo" to continue work from where I stopped.<br />
<br />
=== Correct the TERM variable according to terminal type ===<br />
Instead of [[#Setting_the_correct_term|setting a fixed TERM variable in tmux]], it is possible to set the proper TERM (either {{ic|screen}} or {{ic|screen-256color}}) according to the type of your terminal emulator:<br />
<br />
{{hc|~/.tmux.conf|<br />
## set the default TERM<br />
set -g default-terminal screen<br />
<br />
## update the TERM variable of terminal emulator when creating a new session or attaching a existing session<br />
set -g update-environment 'DISPLAY SSH_ASKPASS SSH_AGENT_PID SSH_CONNECTION WINDOWID XAUTHORITY TERM'<br />
## determine if we should enable 256-colour support<br />
if "[[ ${TERM} =~ 256color || ${TERM} == fbterm ]]" 'set -g default-terminal screen-256color'<br />
}}<br />
<br />
{{hc|1=~/.zshrc|2=<br />
## workaround for handling TERM variable in multiple tmux sessions properly from http://sourceforge.net/p/tmux/mailman/message/32751663/ by Nicholas Marriott<br />
if [[ -n ${TMUX} && -n ${commands[tmux]} ]];then<br />
case $(tmux showenv TERM 2>/dev/null) in<br />
*256color) ;&<br />
TERM=fbterm)<br />
TERM=screen-256color ;;<br />
*)<br />
TERM=screen<br />
esac<br />
fi<br />
}}<br />
<br />
=== Reload an updated configuration without restarting tmux ===<br />
<br />
By default tmux reads {{ic|~/.tmux.conf}} only if it was not already running. To have tmux load a configuration file afterwards, execute:<br />
<br />
tmux source-file <path><br />
<br />
This can be added to {{ic|~/.tmux.conf}} as e. g.:<br />
<br />
bind r source-file <path><br />
<br />
You can also do ^: and type :<br />
source .tmux.conf<br />
<br />
===Template script to run program in new session resp. attach to existing one===<br />
<br />
This script checks for a program presumed to have been started by a previous run of itself. Unless found it creates a new tmux session and attaches to a window named after and running the program. If however the program was found it merely attaches to the session and selects the window.<br />
<br />
#!/bin/bash<br />
<br />
PID=$(pidof $1)<br />
<br />
if [ -z "$PID" ]; then<br />
tmux new-session -d -s main ;<br />
tmux new-window -t main -n $1 "$*" ;<br />
fi<br />
tmux attach-session -d -t main ;<br />
tmux select-window -t $1 ;<br />
exit 0<br />
<br />
A derived version to run ''irssi'' with the ''nicklist'' plugin can be found on [[Irssi#irssi_with_nicklist_in_tmux|its ArchWiki page]].<br />
<br />
=== Terminal emulator window titles ===<br />
If you SSH into a host in a tmux window, you'll notice the window title of your terminal emulator remains to be {{ic|user@localhost}} rather than {{ic|user@server}}. To allow the title bar to adapt to whatever host you connect to, set the following in {{ic|~/.tmux.conf}}<br />
<br />
set -g set-titles on<br />
set -g set-titles-string "#T"<br />
<br />
For {{ic|set-titles-string}}, {{ic|#T}} will display {{ic|user@host:~}} and change accordingly as you connect to different hosts.<br />
<br />
=== Automatic layouting ===<br />
When creating new splits or destroying older ones the currently selected layout isn't applied. To fix that, add following binds which will apply the currently selected layout to new or remaining panes:<br />
<br />
bind-key -n M-c kill-pane \; select-layout<br />
bind-key -n M-n split-window \; select-layout<br />
<br />
=== Vim friendly configuration ===<br />
<br />
See [https://gist.github.com/anonymous/6bebae3eb9f7b972e6f0] for a configuration friendly to [[vim]] users.<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 BBS topic]<br />
* [http://www.dayid.org/os/notes/tm.html Screen and tmux feature comparison]<br />
* [https://github.com/Lokaltog/powerline powerline], a dynamic statusbar for tmux<br />
* [https://github.com/tmux-plugins Plugins for tmux]<br />
<br />
'''Tutorials'''<br />
<br />
* [http://mutelight.org/articles/practical-tmux Practical Tmux]<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux FAQ (OpenBSD)]<br />
* [http://www.openbsd.org/cgi-bin/man.cgi?query=tmux man page (OpenBSD)]<br />
* [http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer/ Tmux tutorial Part 1] and [http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-terminal-multiplexer-part-2 Part 2]</div>Moviurohttps://wiki.archlinux.org/index.php?title=Btrfs_-_Tips_and_tricks&diff=427384Btrfs - Tips and tricks2016-03-23T14:25:05Z<p>Moviuro: document --reflink=auto: cp(1) can save lots of disk space on btrfs.</p>
<hr />
<div>[[Category:File systems]]<br />
{{Merge|Btrfs|This article should have been a "Tips and tricks" sub-section instead of a new page. See discussion:}}<br />
<br />
== coreutils ==<br />
<br />
=== cp(1) ===<br />
<br />
On btrfs, you can use file-level cloning. (see: http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/3/: ''"File-level cloning" means that I can make a fully writable clone copy of one of these several-hundred-gigabyte files in an instant.'').<br />
{{bc|<nowiki>cp () {<br />
command cp --reflink=auto "$@"<br />
}</nowiki>}}<br />
That way, you just use Copy-on-Write to copy files, achieving lightning-fast copy of huge files, along with the benefit of ~0 space usage. You can clone a full virtual machine without using any extra storage.<br />
<br />
== Snapshots ==<br />
<br />
=== Automatic snapshots on each boot ===<br />
<br />
It is possible to automatically save the then current state of a btrfs subvolume during system boot. Two files are needed to accomplish this, a script which snapshots btrfs subvolumes and a [[systemd]] unit file to run the script during the boot process.<br />
<br />
==== Requirements ====<br />
<br />
The root filesystem must have been installed into its own dedicated btrfs subvolume and the btrfs-root where all subvolumes reside has to be accessible.<br />
<br />
{{hc|/etc/fstab|<br />
<nowiki># ...<br />
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX / btrfs defaults,subvol=__current/ROOT 0 0<br />
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /run/btrfs-root btrfs defaults,compress=lzo 0 0<br />
<br />
# just for the below example:<br />
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /var btrfs defaults,subvol=__current/var 0 0<br />
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /opt btrfs defaults,subvol=__current/opt 0 0<br />
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /home btrfs defaults,subvol=__current/home 0 0<br />
# ...<br />
</nowiki>}}<br />
<br />
==== Snapshot script ====<br />
<br />
An example script to snapshot the btrfs subvolumes mounted under ''/'' is listed further below. The script will automatically detect the names of all subvolumes mounted under ''/'' and create snapshots of the same names under a directory specified by the caller.<br />
<br />
What the script does, is to delete all snapshots from the state the system was in at last boot, make new snapshots, and alter the /etc/[[fstab]] file of the snapshot of the root subvolume to allow it to be booted without manual configuration.<br />
<br />
When called like this ...<br />
{{bc|# bash /usr/local/bin/snapshot_current_system_state.sh '/run/btrfs-root' '__current/ROOT' '__snapshot/__state_at_last_successful_boot'}}<br />
the following structure will result:<br />
<br />
{{hc|<nowiki>$ btrfs subvolume list '/'</nowiki>|<br />
<nowiki>ID 257 gen 1134 top level 5 path __current/ROOT<br />
ID 258 gen 1137 top level 5 path __current/var<br />
ID 259 gen 1129 top level 5 path __current/opt<br />
ID 260 gen 1137 top level 5 path __current/home<br />
ID 277 gen 1128 top level 5 path __snapshot/__state_at_last_successful_boot/__current/ROOT<br />
ID 278 gen 1128 top level 5 path __snapshot/__state_at_last_successful_boot/__current/var<br />
ID 279 gen 1129 top level 5 path __snapshot/__state_at_last_successful_boot/__current/opt<br />
ID 280 gen 1130 top level 5 path __snapshot/__state_at_last_successful_boot/__current/home<br />
</nowiki>}}<br />
Note that ''var, opt and home'' are subvolumes created by the caller in this example and mounted under '/'. The script detected and snapshotted them automatically. The resulting directory structure is:<br />
{{bc|<nowiki><br />
/run/btrfs-root/__current/ROOT<br />
/run/btrfs-root/__current/var<br />
/run/btrfs-root/__current/opt<br />
/run/btrfs-root/__current/home<br />
/run/btrfs-root/__current/net<br />
/run/btrfs-root/__current/bak<br />
/run/btrfs-root/__snapshot/__state_at_last_successful_boot/__current/ROOT<br />
/run/btrfs-root/__snapshot/__state_at_last_successful_boot/__current/var<br />
/run/btrfs-root/__snapshot/__state_at_last_successful_boot/__current/opt<br />
/run/btrfs-root/__snapshot/__state_at_last_successful_boot/__current/home<br />
</nowiki>}}<br />
<br />
The script below takes 3 parameters:<br />
# The path of the btrfs filesystem root. E. g. {{ic|/run/btrfs-root}},<br />
# The name of the btrfs root subvolume as specified in /etc/[[fstab]]. E. g. {{ic|__current/ROOT}},<br />
# The path where the newly created snapshots will reside without its 1st parameter portion. E. g. {{ic|__snapshot/__state_at_last_successful_boot}} (if the actual path is ''/run/btrfs-root/__snapshot/__state_at_last_successful_boot'')<br />
<br />
{{Warning|This script will delete all snapshots of the same names as the regular subvolume names in the path its third parameter is pointing to. Be careful that the ''3rd parameter is not pointing at the place where your subvolumes reside in'' --- In this example, ''/run/btrfs-root/__current'' as the 3rd parameter would be incorrect and lead to data loss.}}<br />
<br />
{{hc|/usr/local/bin/snapshot_current_system_state.sh|<br />
<nowiki><br />
#!/bin/sh<br />
<br />
# example call: # bash /usr/local/bin/snapshot_current_system_state.sh '/run/btrfs-root' '__current/ROOT' '__snapshot/__state_at_last_successful_boot' <br />
<br />
if [ $# -ne 3 ]<br />
then<br />
/usr/bin/echo -e "This script requires three parameters:\n1st parameter: The path of the btrfs filesystem root. e. g. /run/btrfs-root\n2nd parameter: The name of the btrfs root volume as specified in /etc/fstab. E. g. __current/ROOT\n3rd parameter: The path where the newly created snapshots will reside without its 1st parameter portion. E. g. __snapshot/__state_at_last_successful_boot\nCAUTION: This script will delete all snapshots of the same name as the regular volume names in the path parameter 3 is pointing to."<br />
exit 0<br />
fi<br />
<br />
btrfs_root="${1}" # example: '/run/btrfs-root'<br />
path_to_root_volume="${2}" # example: '__current/ROOT'<br />
path_to_snapshots="${3}" # example: '__snapshot/__state_at_last_successful_boot'<br />
<br />
# take no snapshots when booted into a snapshot<br />
if [ -e '/SNAPSHOT-TIMESTAMP' ]<br />
then<br />
exit 0<br />
fi<br />
<br />
# anti recursive snapshots<br />
for subvolume in $(/usr/bin/btrfs subvolume list '/' | /usr/bin/awk '{print $NF}') # scan<br />
do<br />
path_to_snapshot="${btrfs_root}/${path_to_snapshots}/${subvolume}"<br />
<br />
if [ -d "${path_to_snapshot}" ]<br />
then<br />
/usr/bin/btrfs subvolume delete "${path_to_snapshot}"<br />
fi <br />
done<br />
<br />
subvolumes="$(/usr/bin/btrfs subvolume list '/' | /usr/bin/awk '{print $NF}')" # rescan<br />
for subvolume in $subvolumes<br />
do<br />
snapshot_directory="${btrfs_root}/${path_to_snapshots}/$(/usr/bin/dirname ${subvolume})"<br />
<br />
if [ ! -d "${snapshot_directory}" ]<br />
then<br />
/usr/bin/mkdir -p "${snapshot_directory}" <br />
fi <br />
<br />
/usr/bin/btrfs subvolume snapshot "${btrfs_root}/${subvolume}" "${btrfs_root}/${path_to_snapshots}/${subvolume}" <br />
<br />
if [ "${subvolume}" = "${path_to_root_volume}" ]<br />
then<br />
timestamp="$(/usr/bin/date +%d.%m.%Y-%H:%M:%S)"<br />
<br />
/usr/bin/echo -e "Arch Linux --- state at last successful boot (nonpersistent) [${timestamp}]\n" > "${btrfs_root}/${path_to_snapshots}/${path_to_root_volume}/etc/issue"<br />
<br />
/usr/bin/echo "${timestamp}" > "${btrfs_root}/${path_to_snapshots}/${path_to_root_volume}/SNAPSHOT-TIMESTAMP"<br />
<br />
sed_path_to_snapshots="$(/usr/bin/echo ${path_to_snapshots} | /usr/bin/sed --posix --regexp-extended 's/\//\\\//g')"<br />
<br />
for subvolumeX in $(echo $subvolumes | /usr/bin/sed --posix --regexp-extended 's/\//\\\//g')<br />
do<br />
/usr/bin/sed --posix --regexp-extended "s/subvol=${subvolumeX}/subvol=${sed_path_to_snapshots}\/${subvolumeX}/g" --in-place "${btrfs_root}/${path_to_snapshots}/${path_to_root_volume}/etc/fstab"<br />
done<br />
fi<br />
done<br />
<br />
/usr/bin/sync<br />
</nowiki>}}<br />
<br />
====systemd unit file====<br />
<br />
Following [[systemd]] unit file will run the script every time the system manages to successfully boot into ''multi-user.target'':<br />
* Example unit file {{ic|/etc/systemd/system/snapshot_current_system_state_upon_boot.service}}:<br />
{{bc|<nowiki><br />
[Unit]<br />
Description=Takes a snapshot of each btrfs subvolume mounted under / after multi-user.target has been reached.<br />
After=multi-user.target<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/bin/sh /usr/local/bin/snapshot_current_system_state.sh '/run/btrfs-root' '__current/ROOT' '__snapshot/__state_at_last_successful_boot'<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
The unit file has to be symlinked by systemd:<br />
<br />
# systemctl enable snapshot_current_system_state_upon_boot.service<br />
<br />
=== Booting into snapshots ===<br />
<br />
In order to boot into a subvolume the ''rootflags=subvol='' option has to be used on the kernel line. The ''subvol='' mount options in {{ic|/etc/fstab}} of the snapshot to boot into also have to be specified correctly.<br />
{{Note|If using the example [[#Snapshot script|script above]], the {{ic|/etc/fstab}} of the snapshot of the root subvolume is set automatically.}} <br />
<br />
==== GRUB ====<br />
<br />
* Example menue entry {{ic|/etc/grub.d/40_custom}}:<br />
{{bc|<nowiki># ....<br />
menuentry "Arch Linux --- state at last successfull boot (nonpersistent)" {<br />
linux /vmlinuz-linux root=/dev/disk/by-uuid/<UUID of btrfs-root> rootflags=subvol=__snapshot/__state_at_last_successful_boot/__current/ROOT init=/usr/lib/systemd/systemd ro quiet<br />
initrd /initramfs-linux.img<br />
}<br />
# ...<br />
</nowiki>}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} has to be executable:<br />
# chmod 700 /etc/grub.d/40_custom<br />
<br />
{{ic|/boot/grub/grub.cfg}} has to be recreated:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
== Backup solutions ==<br />
<br />
* [[Snapper]] is a command-line program for filesystem snapshot management. It can create and compare snapshots, revert between snapshots, and supports automatic snapshots timelines.<br />
<br />
More tools are available, see [https://btrfs.wiki.kernel.org/index.php/UseCases#How_can_I_use_btrfs_for_backups.2Ftime-machine.3F official btrfs wiki].<br />
<br />
== Corruption Recovery ==<br />
<br />
{{Out of date|btrfsck depreceated. Use btrfs-check. See its manpage.}}<br />
<br />
Btrfs does not usually need to do fsck, but in the event that it does the file-system must not be mounted, not even read-only. This makes it difficult to fix! One solution is to use a boot disk to run {{ic|btrfsck --repair /dev/<whatever>}}, but with a little prior thought, there is an easier way:<br />
<br />
Before anything breaks, edit {{ic|/etc/mkinitcpio.conf}} so it has {{ic|btrfsck}}:<br />
BINARIES="/usr/bin/btrfsck"<br />
<br />
Regenerate the initramfs:<br />
# mkinitcpio -p linux<br />
<br />
Then, when the worst happens, use {{ic|grub}}, or whatever, to add "break" to the kernel command line, and boot. The system should stop at a shell in the initramfs, before the btrfs partition has been mounted, and {{ic|btrfsck}} should be installed ready. You can then repair the system like this:<br />
<br />
# btrfsck --repair /dev/<whatever><br />
<br />
{{Note|If the fsck process has to invalidate the space cache (and/or other caches?) then it is normal for a subsequent boot to hang up for a while (it may give console messages about btrfs-transaction being hung). The system should recover from this after a while.}}</div>Moviurohttps://wiki.archlinux.org/index.php?title=IPv6&diff=426155IPv62016-03-17T10:08:19Z<p>Moviuro: /* systemd-networkd */ No longer broken IPv6 privacy extensions</p>
<hr />
<div>[[Category:Networking]]<br />
[[es:IPv6]]<br />
[[ja:IPv6]]<br />
[[pt:IPv6]]<br />
[[ru:IPv6]]<br />
[[zh-CN:IPv6]]<br />
{{Related articles start}}<br />
{{Related|IPv6 tunnel broker setup}}<br />
{{Related articles end}}<br />
<br />
In Arch Linux, IPv6 is enabled by default.<br />
<br />
== Neighbor discovery ==<br />
<br />
Pinging the multicast address {{ic|ff02::1}} results in all hosts in link-local scope responding. An interface has to be specified:<br />
<br />
$ ping ff02::1%eth0<br />
<br />
With a ping to the multicast address {{ic|ff02::2}} only routers will respond.<br />
<br />
If you add an option {{ic|-I ''your-global-ipv6''}}, link-local hosts will respond with their link-global scope addresses. The interface can be omitted in this case:<br />
<br />
$ ping -I 2001:4f8:fff6::21 ff02::1<br />
<br />
== Stateless autoconfiguration (SLAAC) ==<br />
<br />
The easiest way to acquire an IPv6 address as long as your network is configured is through ''Stateless address autoconfiguration'' (SLAAC for short). The address is automatically inferred from the prefix that your router advertises and requires neither further configuration nor specialized software such as a DHCP client.<br />
<br />
=== For clients ===<br />
<br />
If you are using [[netctl]] you just need to add the following line to your ethernet or wireless configuration.<br />
<br />
IP6=stateless<br />
<br />
If you are using [[NetworkManager]] then it automatically enables IPv6 addresses if there are advertisements for them in the network.<br />
<br />
Please note that stateless autoconfiguration works on the condition that IPv6 icmp packets are allowed throughout the network. So for the client side the {{ic|ipv6-icmp}} packets must be accepted. If you are using the [[Simple stateful firewall]]/[[iptables]] you only need to add:<br />
<br />
-A INPUT -p ipv6-icmp -j ACCEPT<br />
<br />
If you are using an other firewall frontend (ufw, shorewall, etc) consult their documentation on how to enable the {{ic|ipv6-icmp}} packets.<br />
<br />
=== For gateways ===<br />
<br />
To properly hand out IPv6s to the network clients we will need to use an advertising daemon. The standard tool for this job is {{Pkg|radvd}} and is available in [[official repositories]]. Configuration of radvd is fairly simple. Edit {{ic|/etc/radvd.conf}} to include<br />
<br />
# replace LAN with your LAN facing interface<br />
interface LAN {<br />
AdvSendAdvert on;<br />
MinRtrAdvInterval 3;<br />
MaxRtrAdvInterval 10;<br />
prefix ::/64 {<br />
AdvOnLink on;<br />
AdvAutonomous on;<br />
AdvRouterAddr on;<br />
};<br />
};<br />
<br />
The above configuration will tell clients to autoconfigure themselves using addresses from the advertised /64 block. Please note that the above configuration advertises ''all available prefixes'' assigned to the LAN facing interface. If you want to limit the advertised prefixes instead of {{ic|::/64}} use the desired prefix, eg {{ic|2001:DB8::/64}}. The {{ic|prefix}} block can be repeated many times for more prefixes.<br />
<br />
The gateway must also allow the traffic of {{ic|ipv6-icmp}} packets on all basic chains. For the [[Simple stateful firewall]]/[[iptables]] add:<br />
<br />
-A INPUT -p ipv6-icmp -j ACCEPT<br />
-A OUTPUT -p ipv6-icmp -j ACCEPT<br />
-A FORWARD -p ipv6-icmp -j ACCEPT<br />
<br />
Adjust accordingly for other firewall frontends and do not forget to enable {{ic|radvd.service}}.<br />
<br />
== Privacy extensions ==<br />
When a client acquires an address through SLAAC its IPv6 address is derived from the advertised prefix and the MAC address of the network interface of the client. This may raise security concerns as the MAC address of the computer can be easily derived by the IPv6 address. In order to tackle this problem the ''IPv6 Privacy Extensions'' standard ([https://tools.ietf.org/html/rfc4941 RFC 4941]) has been developed. With privacy extensions the kernel generates a ''temporary'' address that is mangled from the original autoconfigured address. Private addresses are preferred when connecting to a remote server so the original address is hidden. To enable Privacy Extensions reproduce the following steps:<br />
<br />
Add these lines to {{ic|/etc/sysctl.d/40-ipv6.conf}}:<br />
<br />
# Enable IPv6 Privacy Extensions<br />
net.ipv6.conf.all.use_tempaddr = 2<br />
net.ipv6.conf.default.use_tempaddr = 2<br />
net.ipv6.conf.''nic0''.use_tempaddr = 2<br />
...<br />
net.ipv6.conf.''nicN''.use_tempaddr = 2<br />
<br />
Where {{ic|nic0}} to {{ic|nicN}} are your '''N'''etwork '''I'''nterface '''C'''ards. The {{ic|all.use_tempaddr}} or {{ic|default.use_tempaddr}} parameters are not applied to nic's that already exist when the [[sysctl]] settings are executed. <br />
<br />
After a reboot, at the latest, Privacy Extensions should be enabled.<br />
<br />
=== dhcpcd ===<br />
<br />
[[dhcpcd]] includes in its default configuration file since version 6.4.0 the option {{ic|slaac private}}, which enables "Stable Private IPv6 Addresses instead of hardware based ones", implementing [https://tools.ietf.org/html/rfc7217 RFC 7217] ([http://roy.marples.name/projects/dhcpcd/info/8aa9dab00dc72c453aeccbde885ecce27a3d81ff commit]). Therefore, it is not necessary to change anything, except if it is desired to change of IPv6 address more often than each time the system is connected to a new network.<br />
<br />
=== NetworkManager ===<br />
<br />
NetworkManager does not honour the settings placed in {{ic|/etc/sysctl.d/40-ipv6.conf}}. This can be verified by running {{ic|$ ip -6 addr show ''interface''}} after rebooting: no {{ic|scope global '''temporary'''}} address appears besides the regular one.<br />
<br />
To enable IPv6 Privacy Extensions by default, add these lines to {{ic|/etc/NetworkManager/NetworkManager.conf}}<br />
{{hc|/etc/NetworkManager/NetworkManager.conf|2=<br />
...<br />
'''[connection]'''<br />
'''ipv6.ip6-privacy=2'''<br />
}}<br />
<br />
In order to enable IPv6 Privacy Extensions for individual NetworkManager-managed connections, edit the desired connection keyfile in {{ic|/etc/NetworkManager/system-connections/}} and append to its {{ic|[ipv6]}} section the key-value pair {{ic|1=ip6-privacy=2}}:<br />
{{hc|/etc/NetworkManager/system-connections/''example_connection''|2=<br />
...<br />
[ipv6]<br />
method=auto<br />
'''ip6-privacy=2'''<br />
}}<br />
<br />
{{Note|Although it may seem the {{ic|scope global temporary}} IPv6 address created by enabling Privacy Extensions never gets renewed (it never shifts to {{ic|deprecated}} status at the term of its {{ic|valid_lft}} lifetime), it is to be verified over a longer period of time that this address '''does''' indeed change.}}<br />
<br />
=== systemd-networkd ===<br />
<br />
Systemd-networkd also does not honour the settings placed in {{ic|/etc/sysctl.d/40-ipv6.conf}} and needs the option {{ic|IPv6PrivacyExtensions}} to be set.<br />
<br />
See [[systemd-networkd]] and [http://www.freedesktop.org/software/systemd/man/systemd.network.html systemd.network(5) man page] for details.<br />
<br />
== Static address ==<br />
<br />
Sometime using static address can improve security. For example, if your local router uses Neighbor Discovery or radvd ([http://www.apps.ietf.org/rfc/rfc2461.html RFC 2461]), your interface will automatically be assigned an address based its MAC address (using IPv6's Stateless Autoconfiguration). This may be less than ideal for security since it allows a system to be tracked even if the network portion of the IP address changes.<br />
<br />
To assign a static IP address using [[netctl]], look at the example profile in {{ic|/etc/netctl/examples/ethernet-static}}. The following lines are important:<br />
<br />
...<br />
# For IPv6 static address configuration<br />
IP6=static<br />
Address6=('1234:5678:9abc:def::1/64' '1234:3456::123/96')<br />
Routes6=('abcd::1234')<br />
Gateway6='1234:0:123::abcd'<br />
{{Note|1=If you are connected IPv6-only, than you need to determine ipv6 dns server. For example<br />
DNS=('6666:6666::1' '6666:6666::2')<br />
If your provider did not give you ipv6 dns and you are not running your own, you can choose from [[resolv.conf]] article. <br />
}}<br />
<br />
== IPv6 and PPPoE ==<br />
<br />
The standard tool for PPPoE, {{ic|pppd}}, provides support for IPv6 on PPPoE as long as your ISP and your modem support it. Just add the following to {{ic|/etc/ppp/pppoe.conf}}<br />
<br />
+ipv6<br />
<br />
If you are using [[netctl]] for PPPoE then just add the following to your netctl configuration instead<br />
<br />
PPPoEIP6=yes<br />
<br />
== Prefix delegation (DHCPv6-PD) ==<br />
{{Note|This section is targeted towards custom gateway configuration, not client machines. For standard market routers please consult the documentation of your router on how to enable prefix delegation.}}<br />
<br />
Prefix delegation is a common IPv6 deployment technique used by many ISPs. It is a method of assigning a network prefix to a user site (ie. local network). A router can be configured to assign different network prefixes to various subnetworks. The ISP handles out a network prefix using DHCPv6 (usually a {{ic|/56}} or {{ic|/64}}) and a dhcp client assigns the prefixes to the local network. For a simple two interface gateway it practically assigns an IPv6 prefix to the interface connected to to the local network from an address acquired through the interface connected to WAN (or a pseudo-interface such as ppp).<br />
<br />
=== With dibbler ===<br />
<br />
[http://klub.com.pl/dhcpv6/ Dibbler] is a portable DHCPv6 client a server which can be used for Prefix delegation. It is available in the [[AUR]] as {{AUR|dibbler}}.<br />
<br />
If you are using {{ic|dibbler}} edit {{ic|/etc/dibbler/client.conf}}<br />
<br />
log-mode short<br />
log-level 7<br />
# use the interface connected to your WAN<br />
iface "WAN" {<br />
ia<br />
pd<br />
}<br />
<br />
{{Tip|Read manpage '''{{ic|dibbler-client(8)}}''' for more information.}}<br />
<br />
=== With dhcpcd ===<br />
<br />
[[Dhcpcd]] apart from IPv4 dhcp support also provides a fairly complete implementation of the DHCPv6 client standard which includes DHCPv6-PD. If you are using {{ic|dhcpcd}} edit {{ic|/etc/dhcpcd.conf}}. You might already be using dhcpcd for IPv4 so just update your existing configuration.<br />
<br />
duid<br />
noipv6rs<br />
waitip 6<br />
# Uncomment this line if you are running dhcpcd for IPv6 only.<br />
#ipv6only<br />
<br />
# use the interface connected to WAN<br />
interface WAN<br />
ipv6rs<br />
iaid 1<br />
# use the interface connected to your LAN<br />
ia_pd 1 LAN<br />
#ia_pd 1/::/64 LAN/0/64<br />
<br />
This configuration will ask for a prefix from WAN interface ({{ic|WAN}}) and delegate it to the internal interface ({{ic|LAN}}).<br />
In the event that a {{ic|/64}} range is issued, you will need to use the 2nd {{ic|ia_pd instruction}} that is commented out instead.<br />
It will also disable router solicitations on all interfaces except for the WAN interface ({{ic|WAN}}).<br />
<br />
{{Tip|Also read: manpages '''{{ic|dhcpcd(8)}}''' and '''{{ic|dhcpcd.conf(5)}}'''.}}<br />
<br />
=== With WIDE-DHCPv6 ===<br />
<br />
[http://wide-dhcpv6.sourceforge.net/ WIDE-DHCPv6] is an open-source implementation of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) originally developed by the KAME project. It is available in the [[AUR]] as {{AUR|wide-dhcpv6}}.<br />
<br />
If you are using {{ic|wide-dhcpv6}} edit {{ic|/etc/wide-dhcpv6/dhcp6c.conf}}<br />
<br />
# use the interface connected to your WAN<br />
interface WAN {<br />
send ia-pd 0;<br />
};<br />
<br />
id-assoc pd 0 {<br />
# use the interface connected to your LAN<br />
prefix-interface LAN {<br />
sla-id 1;<br />
sla-len 8;<br />
};<br />
};<br />
<br />
{{Note|1={{ic|sla-len}} should be set so that {{ic|1=(WAN-prefix) + (sla-len) = 64}}. In this case it is set up for a {{ic|/56}} prefix 56+8=64. For a {{ic|/64}} prefix {{ic|sla-len}} should be {{ic|0}}.}}<br />
<br />
To enable/start wide-dhcpv6 client use the following command. Change {{ic|WAN}} with the interface that is connected to your WAN.<br />
# systemctl enable/start dhcp6c@WAN.service<br />
<br />
{{Tip|Read manpages '''{{ic|dhcp6c(8)}}''' and '''{{ic|dhcp6c.conf(5)}}''' for more information.}}<br />
<br />
== IPv6 on Comcast ==<br />
<br />
{{ic|dhcpcd -4}} or {{ic|dhcpcd -6}} worked using a Motorola SURFBoard 6141 and a Realtek RTL8168d/8111d. Either would work, but would not run dual stack: both protocols and addresses on one interface. (The {{ic|-6}} command would not work if {{ic|-4}} ran first, even after resetting the interface. And when it did, it gave the NIC a /128 address.) Try these commands:<br />
<br />
# dhclient -4 enp3s0<br />
# dhclient -P -v enp3s0<br />
<br />
The {{ic|-P}} argument grabs a lease of the IPv6 prefix only. {{ic|-v}} writes to {{ic|stdout}} what is also written to {{ic|/var/lib/dhclient/dhclient6.leases}}:<br />
<br />
Bound to *:546<br />
Listening on Socket/enp3s0<br />
Sending on Socket/enp3s0<br />
PRC: Confirming active lease (INIT-REBOOT).<br />
XMT: Forming Rebind, 0 ms elapsed.<br />
XMT: X-- IA_PD a1:b2:cd:e2<br />
XMT: | X-- Requested renew +3600<br />
XMT: | X-- Requested rebind +5400<br />
XMT: | | X-- '''IAPREFIX 1234:5:6700:890::/64'''<br />
<br />
{{ic|IAPREFIX}} is the necessary value. Substitute {{ic|::1}} before the CIDR slash to make the prefix a real address:<br />
<br />
# ip -6 addr add 1234:5:6700:890::1/64 dev enp3s0<br />
<br />
== Disable IPv6 ==<br />
<br />
{{Note|The Arch kernel has IPv6 support built in directly, therefore a module cannot be blacklisted.}}<br />
<br />
{{Expansion|Add reasons why users may want to disable IPv6, such as low-quality DNS servers or firewall rules}}<br />
<br />
=== Disable functionality ===<br />
{{Warning|Disabling the IPv6 stack can break certain programs which expect it to be enabled. {{bug|46297}}}}<br />
<br />
Adding {{ic|1=ipv6.disable=1}} to the kernel line disables the whole IPv6 stack, which is likely what you want if you are experiencing issues. See [[Kernel parameters]] for more information.<br />
<br />
Alternatively, adding {{ic|1=ipv6.disable_ipv6=1}} instead will keep the IPv6 stack functional but will not assign IPv6 addresses to any of your network devices.<br />
<br />
One can also avoid assigning IPv6 addresses to specific network interfaces by adding the following sysctl config to {{ic|/etc/sysctl.d/40-ipv6.conf}}:<br />
<br />
# Disable IPv6<br />
net.ipv6.conf.all.disable_ipv6 = 1<br />
net.ipv6.conf.''nic0''.disable_ipv6 = 1<br />
...<br />
net.ipv6.conf.''nicN''.disable_ipv6 = 1<br />
<br />
Note that you must list all of the targeted interfaces explicitly, as disabling {{ic|all.disable_ipv6}} does not apply to interfaces that are already "up" when sysctl settings are applied.<br />
<br />
Note 2, if disabling IPv6 by sysctl, you should comment out the IPv6 hosts in your {{ic|/etc/hosts}}:<br />
<br />
#<ip-address> <hostname.domain.org> <hostname><br />
127.0.0.1 localhost.localdomain localhost<br />
#::1 localhost.localdomain localhost<br />
<br />
otherwise there could be some connection errors because hosts are resolved to their IPv6 address which is not reachable.<br />
<br />
=== Other programs ===<br />
<br />
Disabling IPv6 functionality in the kernel does not prevent other programs from trying to use IPv6. In most cases, this is completely harmless, but if you find yourself having issues with that program, you should consult the program's manual pages for a way to disable that functionality.<br />
<br />
==== dhcpcd ====<br />
<br />
''dhcpcd'' will continue to harmlessly attempt to perform IPv6 router solicitation. To disable this, as stated in the {{ic|dhcpcd.conf (5)}} [[man page]], add the following to {{ic|/etc/dhcpcd.conf}}:<br />
<br />
noipv6rs<br />
noipv6<br />
<br />
==== NetworkManager ====<br />
<br />
{{Poor writing|Specific approach to disable via GUI}}<br />
<br />
To disable IPv6 in NetworkManager, right click the network status icon, and select ''Edit Connections > Wired > ''Network name'' > Edit > IPv6 Settings > Method > Ignore/Disabled''<br />
<br />
Then click "Save".<br />
<br />
==== ntpd ====<br />
<br />
Following advice in [[Systemd#Drop-in snippets]], change how systemd starts {{ic|ntpd.service}}:<br />
<br />
# systemctl edit ntpd.service<br />
<br />
This will create a drop-in snippet that will be run instead of the default {{ic|ntpd.service}}. The {{ic|-4}} flag prevents IPv6 from being used by the ntp daemon. Put the following into the drop-in snippet:<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/ntpd -4 -g -u ntp:ntp<br />
<br />
which first clears the previous {{ic|ExecStart}}, and then replaces it with one that includes the {{ic|-4}} flag.<br />
<br />
== See also ==<br />
<br />
* [https://www.kernel.org/doc/Documentation/networking/ipv6.txt IPv6] - kernel.org documentation<br />
* [http://www.ipsidixit.net/2012/08/09/ipv6-temporary-addresses-and-privacy-extensions/ IPv6 temporary addresses] - a summary about temporary addresses and privacy extensions<br />
* [http://tldp.org/HOWTO/Linux+IPv6-HOWTO/x513.html IPv6 prefixes] - a summary of prefix types<br />
* [http://tldp.org/HOWTO/Linux+IPv6-HOWTO/proc-sys-net-ipv6..html net.ipv6 options] - documentation of kernel parameters</div>Moviurohttps://wiki.archlinux.org/index.php?title=Systemd-networkd&diff=426154Systemd-networkd2016-03-17T10:07:42Z<p>Moviuro: /* IPv6 privacy extensions */ No longer broken</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Network configuration]]<br />
[[Category:Virtualization]]<br />
[[es:Systemd-networkd]]<br />
[[fr:systemd-networkd]]<br />
[[ja:systemd-networkd]]<br />
[[ru:Systemd-networkd]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|systemd-nspawn}}<br />
{{Related|Network bridge}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related|:Category:Network configuration}}<br />
{{Related articles end}}<br />
<br />
''systemd-networkd'' is a system daemon that manages network configurations. It detects and configures network devices as they appear; it can also create virtual network devices. This service can be especially useful to set up complex network configurations for a container managed by [[systemd-nspawn]] or for virtual machines. It also works fine on simple connections.<br />
<br />
== Basic usage ==<br />
The {{Pkg|systemd}} package is part of the default Arch installation and contains all needed files to operate a wired network. Wireless adapters can be setup by other services, such as [[wpa_supplicant]], which are covered later in this article.<br />
<br />
=== Required services and setup ===<br />
<br />
To use ''systemd-networkd'', [[start]] the following two services and [[enable]] them to run on system boot:<br />
<br />
* {{ic|systemd-networkd.service}}<br />
* {{ic|systemd-resolved.service}}<br />
<br />
{{Note|''systemd-resolved'' is actually required only if you are specifying DNS entries in ''.network'' files or if you want to obtain DNS addresses from networkd's DHCP client.}}<br />
<br />
For compatibility with [[resolv.conf]], delete or rename the existing file and create the following symbolic link:<br />
<br />
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
<br />
Optionally, if you wish to use the local DNS stub resolver of ''systemd-resolved'' (and thus use LLMNR and DNS merging per interface), replace {{ic|dns}} with {{ic|resolve}} in {{ic|/etc/nsswitch.conf}}:<br />
<br />
hosts: files '''resolve''' myhostname<br />
<br />
See {{ic|man systemd-resolved}} and {{ic|man resolved.conf}} and [https://github.com/systemd/systemd/blob/master/README#L205 Systemd README].<br />
<br />
{{Note|Systemd's {{ic|resolve}} may not search the local domain when given just the hostname, even when {{ic|1=UseDomains=yes}} or {{ic|1=Domains=[domain-list]}} is present in the appropriate {{ic|.network}} file, and that file produces the expected {{ic|search [domain-list]}} in {{ic|resolv.conf}}. If you run into this problem:<br />
* Switch to using fully-qualified domain names<br />
* Use {{ic|/etc/hosts}} to resolve hostnames<br />
* Fall back to using glibc's {{ic|dns}} instead of using systemd's {{ic|resolve}}}}<br />
<br />
=== Configuration examples ===<br />
All configurations in this section are stored as {{ic|foo.network}} in {{ic|/etc/systemd/network}}. For a full listing of options and processing order, see [[#Configuration files]] and the {{ic|systemd.network}} man page.<br />
<br />
Systemd/udev automatically assigns predictable, stable network interface names for all local Ethernet, WLAN, and WWAN interfaces. Use {{ic|networkctl list}} to list the devices on the system.<br />
<br />
After making changes to a configuration file, [[restart]] {{ic|systemd-networkd.service}}.<br />
<br />
{{Note|In the examples below, '''enp1s0''' is the wired adapter and '''wlp2s0''' is the wireless adapter. These names can be different on different systems.}}<br />
<br />
==== Wired adapter using DHCP ====<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
DHCP=ipv4</nowiki><br />
}}<br />
<br />
==== Wired adapter using a static IP ====<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
Address=10.1.10.9/24<br />
Gateway=10.1.10.1</nowiki><br />
}}<br />
<br />
See the {{ic|systemd.network(5)}} man page for more network options such as specifying DNS servers and a broadcast address.<br />
<br />
==== Wireless adapter ====<br />
In order to connect to a wireless network with ''systemd-networkd'', a wireless adapter configured with another service such as [[wpa_supplicant]] is required. In this example, the corresponding systemd service file that needs to be enabled is {{ic|wpa_supplicant@wlp2s0.service}}.<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
If the wireless adapter has a static IP address, the configuration is the same (except for the interface name) as in a [[#Wired adapter using a static IP|wired adapter]].<br />
<br />
==== Wired and wireless adapters on the same machine ====<br />
<br />
This setup will enable a DHCP IP for both a wired and wireless connection making use of the metric directive to allow the kernel the decide on-the-fly which one to use. This way, no connection downtime is observed when the wired connection is unplugged.<br />
<br />
The kernel's route metric (same as configured with ''ip'') decides which route to use for outgoing packets, in cases when several match. This will be the case when both wireless and wired devices on the system have active connections. To break the tie, the kernel uses the metric. If one of the connections is terminated, the other automatically wins without there being a gap with nothing configured (ongoing transfers may still not deal with this nicely but that is at a different OSI layer).<br />
<br />
{{Note|The '''Metric''' option is for static routes while the '''RouteMetric''' option is for setups not using static routes.}}<br />
<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
<br />
[DHCP]<br />
RouteMetric=10<br />
</nowiki>}}<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
<br />
[DHCP]<br />
RouteMetric=20<br />
</nowiki>}}<br />
<br />
==== IPv6 privacy extensions ====<br />
<br />
If you are using IPv6 you might also want to set the {{ic|IPv6PrivacyExtensions}} option as settings placed in {{ic|/etc/sysctl.d/40-ipv6.conf}} are not honored.<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=yes<br />
IPv6PrivacyExtensions=true<br />
<br />
[DHCP]<br />
RouteMetric=20<br />
</nowiki>}}<br />
<br />
== Configuration files ==<br />
<br />
Configuration files are located in {{ic|/usr/lib/systemd/network}}, the volatile runtime network directory {{ic|/run/systemd/network}} and, the local administration network directory {{ic|/etc/systemd/network}}. Files in {{ic|/etc/systemd/network}} have the highest priority.<br />
<br />
There are three types of configuration files. <br />
<br />
* '''.network''' files. They will apply a network configuration for a ''matching'' device<br />
* '''.netdev''' files. They will create a ''virtual network device'' for a ''matching'' environment<br />
* '''.link''' files. When a network device appears, [[udev]] will look for the first ''matching'' '''.link''' file<br />
<br />
They all follow the same rules: <br />
<br />
* If '''all''' conditions in the {{ic|[Match]}} section are matched, the profile will be activated<br />
* an empty {{ic|[Match]}} section means the profile will apply in any case (can be compared to the {{ic|*}} joker)<br />
* each entry is a key with the {{ic|1=NAME=VALUE}} syntax <br />
* all configuration files are collectively sorted and processed in lexical order, regardless of the directory in which they live<br />
* files with identical name replace each other<br />
<br />
{{Tip|<br />
* to override a system-supplied file in {{ic|/usr/lib/systemd/network}} in a permanent manner (i.e even after upgrade), place a file with same name in {{ic|/etc/systemd/network}} and symlink it to {{ic|/dev/null}}<br />
* the {{ic|*}} joker can be used in {{ic|VALUE}} (e.g {{ic|en*}} will match any Ethernet device)<br />
* following this [https://mailman.archlinux.org/pipermail/arch-general/2014-March/035381.html Arch-general thread], the best practice is to setup specific container network settings ''inside the container'' with '''networkd''' configuration files.<br />
}}<br />
<br />
=== network files ===<br />
<br />
These files are aimed at setting network configuration variables, especially for servers and containers.<br />
<br />
Below is a basic structure of a {{ic|''MyProfile''.network}} file:<br />
<br />
{{hc|/etc/systemd/network/''MyProfile''.network|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[Network]<br />
''a vertical list of keys''<br />
<br />
[Address]<br />
''a vertical list of keys''<br />
<br />
[Route]<br />
''a vertical list of keys''<br />
}}<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=Name=}} the device name (e.g Br0, enp4s0, en*)<br />
* {{ic|1=Host=}} the machine hostname<br />
* {{ic|1=Virtualization=}} check whether the system is executed in a virtualized environment or not. A {{ic|1=Virtualization=no}} key will only apply on your host machine, while {{ic|1=Virtualization=yes}} apply to any container or VM.<br />
<br />
==== [Link] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=MACAddress=}} useful for [[MAC_address_spoofing#Method_1:_systemd-networkd|MAC address spoofing]]<br />
* {{ic|1=MTUBytes=}} the maximum transmission unit in bytes (suffixes K, M, G, are supported and are understood to the base of 1024). Using a larger MTU value ([[Jumbo frames]]) can significantly speed up your network transfers.<br />
<br />
==== [Network] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=DHCP=}} enables [[Wikipedia:Dynamic Host Configuration Protocol|DHCPv4]] and/or DHCPv6 support. Accepts {{ic|yes}}, {{ic|no}}, {{ic|ipv4}} or {{ic|ipv6}}<br />
* {{ic|1=DNS=}} is a [[Wikipedia:Domain Name System|DNS]] server address. You can specify this option more than once<br />
* {{ic|1=Bridge=}} is the name of the bridge to add the link to<br />
* {{ic|1=IPForward=}} defaults to {{ic|no}}. It enables IP forwarding, performing the forwarding according to the routing table and is required for setting up [[Internet sharing]]. Note that turning {{ic|1=IPForward=}} on applies to ''all'' network interfaces. <br />
* {{ic|1=Domains=}} a list of the domains used for DNS host name resolution.<br />
<br />
Please see {{ic|systemd.network(5)}} for details.<br />
<br />
==== [Address] section ====<br />
Most common key in the {{ic|[Address]}} section is:<br />
<br />
* {{ic|1=Address=}} is a static '''IPv4''' or '''IPv6''' address and its prefix length, separated by a {{ic|/}} character (e.g {{ic|192.168.1.90/24}}). This option is '''mandatory''' unless DHCP is used.<br />
<br />
==== [Route] section ====<br />
Most common key in the {{ic|[Route]}} section is:<br />
<br />
* {{ic|1=Gateway=}} is the address of your machine gateway. This option is '''mandatory''' unless DHCP is used.<br />
For an exhaustive key list, please refer to {{ic|systemd.network(5)}}<br />
<br />
{{Tip|you can put the {{ic|1=Address=}} and {{ic|1=Gateway=}} keys in the {{ic|[Network]}} section as a short-hand if {{ic|1=Address=}} contains only an Address key and {{ic|1=Gateway=}} section contains only a Gateway key<br />
}}<br />
<br />
=== netdev files ===<br />
<br />
These files will create virtual network devices.<br />
<br />
Below is a basic structure of a ''Mydevice''.netdev file:<br />
<br />
{{hc|/etc/systemd/network/''MyDevice''.netdev|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[NetDev]<br />
''a vertical list of keys''<br />
}}<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are {{ic|1=Host=}} and {{ic|1=Virtualization=}}<br />
<br />
==== [NetDev] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=Name=}} is the interface name used when creating the netdev. This option is '''compulsory'''<br />
* {{ic|1=Kind=}} is the netdev kind. For example, ''bridge'', ''bond'', ''vlan'', ''veth'', ''sit'', etc. are supported. This option is '''compulsory'''<br />
<br />
For an exhaustive key list, please refer to {{ic|systemd.netdev(5)}}<br />
<br />
=== link files ===<br />
<br />
These files are an alternative to custom udev rules and will be applied by [[udev]] as the device appears.<br />
<br />
Below is a basic structure of a ''Mydevice''.link file:<br />
<br />
{{hc|/etc/systemd/network/''MyDevice''.link|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[Link]<br />
''a vertical list of keys''<br />
}}<br />
<br />
The {{ic|[Match]}} section will determine if a given link file may be applied to a given device, when the {{ic|[Link]}} section specifies the device configuration.<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are {{ic|1=MACAddress=}}, {{ic|1=Host=}} and {{ic|1=Virtualization=}}.<br />
<br />
{{ic|1=Type=}} is the device type (e.g. vlan)<br />
<br />
==== [Link] section ====<br />
<br />
Most common keys are:<br />
<br />
{{ic|1=MACAddressPolicy=}} is either ''persistent'' when the hardware has a persistent MAC address (as most hardware should) or ''random'' , which allows to give a random MAC address when the device appears.<br />
<br />
{{ic|1=MACAddress=}} shall be used when no {{ic|1=MACAddressPolicy=}} is specified.<br />
<br />
{{Note|the system {{ic|/usr/lib/systemd/network/99-default.link}} is generally sufficient for most of the basic cases.}}<br />
<br />
== Usage with containers ==<br />
<br />
The service is available with {{Pkg|systemd}} >= 210. You will want to [[systemd#Basic systemctl usage|enable and start]] the {{ic|systemd-networkd.service}} on the host and container.<br />
<br />
For debugging purposes, it is strongly advised to [[install]] the {{Pkg|bridge-utils}}, {{Pkg|net-tools}} and {{Pkg|iproute2}} packages.<br />
<br />
If you are using ''systemd-nspawn'', you may need to modify the {{ic|systemd-nspawn@.service}} and append boot options to the {{ic|ExecStart}} line. Please refer to {{ic|man 1 systemd-nspawn}} for an exhaustive list of options.<br />
<br />
Note that if you want to take advantage of automatic DNS configuration from DHCP, you need to enable {{ic|systemd-resolved}} and symlink {{ic|/run/systemd/resolve/resolv.conf}} to {{ic|/etc/resolv.conf}}. See {{ic|systemd-resolved.service(8)}} for more details.<br />
<br />
{{Style|Too many points for a tip, some of them are very similar so they could be merged.}}<br />
<br />
{{Tip|1=Before you start to configure your container network, it is useful to:<br />
* disable all your [[netctl]] services. This will avoid any potential conflicts with {{ic|systemd-networkd}} and make all your configurations easier to test. Furthermore, odds are high you will end with few or even no [[netctl]] activated profiles. The {{ic|netctl list}} command will output a list of all your profiles, with the activated one being starred.<br />
* disable the {{ic|systemd-nspawn@.service}} and use the {{ic|systemd-nspawn -bnD /path_to/your_container/}} command as root to boot the container. To log off and shutdown inside the container {{ic|systemctl poweroff}} is used as root. Once the network setting meets your requirements, [[systemd#Basic systemctl usage|enable and start]] {{ic|systemd-nspawn@.service}}<br />
* disable the {{ic|dhcpcd.service}} if enabled on your system, since it activates ''dhcpcd'' on '''all''' interfaces<br />
* make sure you have no [[netctl]] profiles activated in the container, and ensure that {{ic|systemd-networkd.service}} is neither enabled nor started<br />
* make sure you do not have any [[iptables]] rules which can block traffic<br />
* make sure ''packet forwarding'' is [[Internet sharing#Enable packet forwarding|enabled]] if you want to let containers access the internet. Make sure that your {{ic|.network}} file does not accidentally turn off forwarding because if you do not have a {{ic|1=IPForward=1}} setting in it, {{ic|systemd-networkd}} will turn off forwarding on this interface, even if you have it enabled globally.<br />
* when the daemon is started the systemd {{ic|networkctl}} command displays the status of network interfaces.<br />
}}<br />
<br />
{{Note|For the set-up described below, <br />
* we will limit the output of the {{ic|ip a}} command to the concerned interfaces<br />
* we assume the ''host'' is your main OS you are booting to and the ''container'' is your guest virtual machine<br />
* all interface names and IP addresses are only examples<br />
}}<br />
<br />
=== Basic DHCP network ===<br />
<br />
This setup will enable a DHCP IP for host and container. In this case, both systems will share the same IP as they share the same interfaces.<br />
<br />
{{hc|/etc/systemd/network/''MyDhcp''.network|<nowiki><br />
[Match]<br />
Name=en*<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
Then, [[enable]] and start {{ic|systemd-networkd.service}} on your container.<br />
<br />
You can of course replace {{ic|en*}} by the full name of your ethernet device given by the output of the {{ic|ip link}} command.<br />
<br />
* on host and container:<br />
<br />
{{hc|$ ip a|<br />
2: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.72/24 brd 192.168.1.255 scope global enp7s0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
By default, hostname received from the DHCP server will be used as the transient hostname.<br />
<br />
To change it add {{ic|1=UseHostname=false}} in section {{ic|[DHCPv4]}}<br />
{{hc|/etc/systemd/network/''MyDhcp''.network|<nowiki><br />
[DHCPv4]<br />
UseHostname=false<br />
</nowiki>}}<br />
<br />
If you did not want to configure a DNS in {{ic|/etc/resolv.conf}} and want to rely on DHCP for setting it up, you need to [[enable]] {{ic|systemd-resolved.service}} and symlink {{ic|/run/systemd/resolve/resolv.conf}} to {{ic|/etc/resolv.conf}}<br />
<br />
# ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
<br />
See {{ic|systemd-resolved.service(8)}} for more details.<br />
<br />
=== DHCP with two distinct IP ===<br />
<br />
==== Bridge interface ====<br />
<br />
Create a virtual bridge interface <br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.netdev|<nowiki><br />
[NetDev]<br />
Name=br0<br />
Kind=bridge<br />
</nowiki>}}<br />
<br />
[[Restart]] {{ic|systemd-networkd.service}} to have systemd create the bridge.<br />
<br />
On host and container:<br />
<br />
{{hc|$ ip a|<br />
3: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default <br />
link/ether ae:bd:35:ea:0c:c9 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
Note that the interface br0 is listed but is DOWN.<br />
<br />
==== Bind ethernet to bridge ====<br />
<br />
Modify the {{ic|/etc/systemd/network/''MyDhcp''.network}} to remove the DHCP, as the bridge requires an interface to bind to with no IP, and add a key to bind this device to br0. Let us change its name to a more relevant one.<br />
<br />
{{hc|/etc/systemd/network/''MyEth''.network|<nowiki><br />
[Match]<br />
Name=en*<br />
<br />
[Network]<br />
Bridge=br0<br />
</nowiki>}}<br />
<br />
==== Bridge network ====<br />
<br />
Create a network profile for the Bridge<br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.network|<nowiki><br />
[Match]<br />
Name=br0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
==== Add option to boot the container ====<br />
<br />
As we want to give a separate IP for host and container, we need to ''Disconnect'' networking of the container from the host. To do this, add this option {{ic|1=--network-bridge=br0}} to your container boot command.<br />
<br />
# systemd-nspawn --network-bridge&#61;br0 -bD /path_to/my_container<br />
<br />
==== Result ====<br />
<br />
* on host<br />
<br />
{{hc|$ ip a|<br />
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default <br />
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.87/24 brd 192.168.1.255 scope global br0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link <br />
valid_lft forever preferred_lft forever<br />
6: vb-''MyContainer'': <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000<br />
link/ether d2:7c:97:97:37:25 brd ff:ff:ff:ff:ff:ff<br />
inet6 fe80::d07c:97ff:fe97:3725/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
* on container<br />
<br />
{{hc|$ ip a|<br />
2: host0: <BROADCAST,MULTICAST,ALLMULTI,AUTOMEDIA,NOTRAILERS,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
link/ether 5e:96:85:83:a8:5d brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.73/24 brd 192.168.1.255 scope global host0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5c96:85ff:fe83:a85d/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
==== Notice ====<br />
<br />
* we have now one IP address for Br0 on the host, and one for host0 in the container<br />
* two new interfaces have appeared: {{ic|vb-''MyContainer''}} in the host and {{ic|host0}} in the container. This comes as a result of the {{ic|1=--network-bridge=br0}} option. This option ''implies'' another option, {{ic|--network-veth}}. This means a ''virtual Ethernet link'' has been created between host and container.<br />
* the DHCP address on {{ic|host0}} comes from the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file.<br />
* on host<br />
<br />
{{hc|$ brctl show|<br />
bridge name bridge id STP enabled interfaces<br />
br0 8000.14dae9b57a88 no enp7s0<br />
vb-''MyContainer''<br />
}}<br />
<br />
the above command output confirms we have a bridge with two interfaces binded to.<br />
<br />
* on host<br />
<br />
{{hc|$ ip route|<br />
default via 192.168.1.254 dev br0 <br />
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.87<br />
}}<br />
<br />
* on container<br />
<br />
{{hc|$ ip route|<br />
default via 192.168.1.254 dev host0 <br />
192.168.1.0/24 dev host0 proto kernel scope link src 192.168.1.73<br />
}}<br />
<br />
the above command outputs confirm we have activated {{ic|br0}} and {{ic|host0}} interfaces with an IP address and Gateway 192.168.1.254. The gateway address has been automatically grabbed by ''systemd-networkd''<br />
<br />
{{hc|$ cat /run/systemd/resolve/resolv.conf|<br />
nameserver 192.168.1.254<br />
}}<br />
<br />
=== Static IP network ===<br />
<br />
Setting a static IP for each device can be helpful in case of deployed web services (e.g FTP, http, SSH). Each device will keep the same MAC address across reboots if your system {{ic|/usr/lib/systemd/network/99-default.link}} file has the {{ic|1=MACAddressPolicy=persistent}} option (it has by default). Thus, you will easily route any service on your Gateway to the desired device.<br />
First, we shall get rid of the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file. To do it in a permanent way (e.g even after upgrades), do the following on container. This will mask the file {{ic|/usr/lib/systemd/network/80-container-host0.network}} since files of the same name in {{ic|/etc/systemd/network}} take priority over {{ic|/usr/lib/systemd/network}}.<br />
<br />
# ln -sf /dev/null /etc/systemd/network/80-container-host0.network<br />
<br />
Then, [[systemd#Basic systemctl usage|enable and start]] {{ic|systemd-networkd}} on your container.<br />
<br />
The needed configuration files:<br />
* on host <br />
{{Accuracy|In the listing of configuration files, /etc/systemd/network/MyBridge.netdev has the .netdev extension. But, the MyBridge.network example file has the .network extension.}}<br />
<br />
/etc/systemd/network/''MyBridge''.netdev<br />
/etc/systemd/network/''MyEth''.network<br />
<br />
A modified ''MyBridge''.network<br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.network|<nowiki><br />
[Match]<br />
Name=br0<br />
<br />
[Network]<br />
DNS=192.168.1.254<br />
Address=192.168.1.87/24<br />
Gateway=192.168.1.254<br />
</nowiki>}}<br />
<br />
* on container<br />
<br />
{{hc|/etc/systemd/network/''MyVeth''.network|<nowiki><br />
[Match]<br />
Name=host0<br />
<br />
[Network]<br />
DNS=192.168.1.254<br />
Address=192.168.1.94/24<br />
Gateway=192.168.1.254<br />
</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html systemd.networkd man page]<br />
* [https://plus.google.com/u/0/+TomGundersen/posts Tom Gundersen, main systemd-networkd developer, G+ home page]<br />
* [https://coreos.com/blog/intro-to-systemd-networkd/ Tom Gundersen posts on Core OS blog]<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1393759#p1393759 How to set up systemd-networkd with wpa_supplicant] (WonderWoofy's walkthrough on Arch forums)</div>Moviurohttps://wiki.archlinux.org/index.php?title=Unbound&diff=420989Unbound2016-02-16T20:59:12Z<p>Moviuro: /* Block advertising */</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[ja:Unbound]]<br />
[[zh-cn:Unbound]]<br />
[https://unbound.net/ Unbound] is a validating, recursive, and caching DNS resolver.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|unbound}} package from [[official repositories]].<br />
<br />
Additionally, {{Pkg|expat}} is required for [[DNSSEC]] validation.<br />
<br />
== Configuration ==<br />
<br />
''unbound'' is easy to configure. There is a sample config file {{ic|/etc/unbound/unbound.conf.example}}, which can be copied to {{ic|/etc/unbound/unbound.conf}} and with the adjustments to the file for your own needs it is enough to run on both IPv4 and IPv6 without access restrictions.<br />
<br />
=== Access control ===<br />
<br />
You can specify the interfaces to answer queries from by IP address. To listen on ''localhost'', use:<br />
<br />
interface: 127.0.0.1<br />
<br />
To listen on all interfaces, use:<br />
<br />
interface: 0.0.0.0<br />
<br />
Access can be further configured via the {{ic|access-control}} option:<br />
<br />
access-control: ''subnet'' ''action''<br />
<br />
For example:<br />
<br />
access-control: 192.168.1.0/24 allow<br />
<br />
''action'' can be one of {{ic|deny}} (drop message), {{ic|refuse}} (polite error reply), {{ic|allow}} (recursive ok), or {{ic|allow_snoop}} (recursive and nonrecursive ok). By default everything is refused except for localhost.<br />
<br />
=== Root hints ===<br />
<br />
For querying a host that is not cached as an address the resolver needs to start at the top of the server tree and query the root servers to know where to go for the top level domain for the address being queried. Therefore it is necessary to put a ''root hints'' file into the ''unbound'' config directory. The simplest way to do this is to run the command:<br />
<br />
{{bc|<nowiki># curl -o /etc/unbound/root.hints https://www.internic.net/domain/named.cache</nowiki>}}<br />
<br />
It is a good idea to run this every six months or so in order to make sure the list of root servers is up to date. This can be done manually or by setting up a [[cron]] job for the task.<br />
<br />
Point ''unbound'' to the {{ic|root.hints}} file:<br />
<br />
root-hints: "/etc/unbound/root.hints"<br />
<br />
=== Set /etc/resolv.conf to use the local DNS server ===<br />
<br />
Edit {{ic|/etc/resolv.conf}} (See also [[resolv.conf]]):<br />
<br />
nameserver 127.0.0.1<br />
<br />
Also if you want to be able to use the hostname of local machine names without the fully qualified domain names, then add a line with the local domain such as:<br />
<br />
domain localdomain.com<br />
nameserver 127.0.0.1<br />
<br />
That way you can refer to local hosts such as mainmachine1.localdomain.com as simply mainmachine1 when using the ssh command, but the drill command below still requires the fully qualified domain names in order to perform lookups.<br />
<br />
Testing the server before making it default can be done using the drill command from the {{Pkg|ldns}} package with examples from internal and external forward and reverse addresses:<br />
<br />
$ drill @127.0.0.1 www.cnn.com<br />
$ drill @127.0.0.1 localmachine.localdomain.com<br />
$ drill @127.0.0.1 -x w.x.y.z <br />
<br />
where {{ic|w.x.y.z}} can be a local or external IP address and the {{ic|-x}} option requests a reverse lookup. Once all is working, and you have {{ic|/etc/resolv.conf}} set to use {{ic|127.0.0.1}} as the nameserver then you no longer need the {{ic|@127.0.0.1}} in the ''drill'' command, and you can test again that it uses the default DNS server - check that the server used as listed at the bottom of the output from each of these commands shows it is {{ic|127.0.0.1}} being queried.<br />
<br />
=== Logging ===<br />
<br />
If you will want logging for ''unbound'', then create a log file which can also be in the same directory, but you can choose any location. One way is then to do as root:<br />
<br />
# touch /etc/unbound/unbound.log<br />
# chown unbound:unbound /etc/unbound/unbound.log<br />
<br />
Then you can include the logging parameter when you set up the main {{ic|unbound.conf}} file as below.<br />
<br />
=== DNSSEC validation ===<br />
<br />
You will need the root server trust key anchor file. It is provided by the {{Pkg|dnssec-anchors}} package (already installed as a dependency), however, ''unbound'' needs read and write access to the file. The {{ic|unbound.service}} service accomplishes this by copying the {{ic|/etc/trusted-key.key}} file to {{ic|/etc/unbound/trusted-key.key}}. You just need to point ''unbound'' to this file:<br />
{{hc|/etc/unbound/unbound.conf|<br />
server:<br />
...<br />
trust-anchor-file: trusted-key.key<br />
...<br />
}}<br />
<br />
Also make sure that if a general [[#Forwarding queries|forward]] to the Google servers had been in place, then comment them out otherwise DNS queries will fail. DNSSEC validation will be done if the DNS server being queried supports it.<br />
<br />
{{Note|Including DNSSEC checking significantly increases DNS lookup times for initial lookups. Once an address is cached locally, then the lookup is virtually instantaneous.}}<br />
<br />
You can now test if DNSSEC is working, using ''drill'' in {{Pkg|ldns}} (installed as dependency):<br />
<br />
drill sigfail.verteiltesysteme.net # should return rcode: SERVFAIL<br />
drill sigok.verteiltesysteme.net # should return rcode: NOERROR<br />
<br />
=== Forwarding queries ===<br />
<br />
If you have a local network which you wish to have DNS queries for and there is a local DNS server that you would like to forward queries to then you should include this line:<br />
<br />
private-address: ''local_subnet/subnet_mask''<br />
<br />
for example:<br />
<br />
private-address: 10.0.0.0/24<br />
<br />
{{note|You can use private-address to protect against DNS Rebind attacks. Therefore you may enable RFC1918 networks (10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16 fd00::/8 fe80::/10). Unbound may enable this feature by default in future releases.}} <br />
<br />
To include a local DNS server for both forward and reverse local addresses a set of lines similar to these below is necessary with a forward and reverse lookup (choose the IP address of the server providing DNS for the local network accordingly by changing 10.0.0.1 in the lines below):<br />
<br />
local-zone: "10.in-addr.arpa." transparent<br />
<br />
This line above is important to get the reverse lookup to work correctly.<br />
<br />
forward-zone:<br />
name: "mynetwork.com."<br />
forward-addr: 10.0.0.1 # Home DNS<br />
<br />
forward-zone:<br />
name: "10.in-addr.arpa."<br />
forward-addr: 10.0.0.1<br />
<br />
{{Note|There is a difference between forward zones and stub zones - stub zones will only work when connected to an authoritative DNS server directly. This would work for lookups from a [[BIND]] DNS server if it is providing authoritative DNS - but if you are referring queries to an ''unbound'' server in which internal lookups are forwarded on to another DNS server, then defining the referral as a stub zone in the machine here will not work. In that case it is necessary to define a forward zone as above, since forward zones can have daisy chain lookups onward to other DNS servers. i.e. forward zones can refer queries to recursive DNS servers. This distinction is important as you do not get any error messages indicating what the problem is if you use a stub zone inappropriately.}}<br />
<br />
You can set up the localhost forward and reverse lookups with the following lines:<br />
<br />
local-zone: "localhost." static<br />
local-data: "localhost. 10800 IN NS localhost."<br />
local-data: "localhost. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"<br />
local-data: "localhost. 10800 IN A 127.0.0.1"<br />
local-zone: "127.in-addr.arpa." static<br />
local-data: "127.in-addr.arpa. 10800 IN NS localhost."<br />
local-data: "127.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 2 3600 1200 604800 10800"<br />
local-data: "1.0.0.127.in-addr.arpa. 10800 IN PTR localhost."<br />
<br />
Then to use specific servers for default forward zones that are outside of the local machine and outside of the local network (i.e. all other queries will be forwarded to them, and then cached) add this to the configuration file (and in this example the first two addresses are the fast google DNS servers):<br />
<br />
forward-zone:<br />
name: "."<br />
forward-addr: 8.8.8.8<br />
forward-addr: 8.8.4.4<br />
forward-addr: 208.67.222.222<br />
forward-addr: 208.67.220.220<br />
<br />
This will make ''unbound'' use Google and OpenDNS servers as the forward zone for external lookups.<br />
<br />
{{Note|OpenDNS strips DNSSEC records from responses. Do not use the above forward zone if you want to enable [[#DNSSEC validation]].}}<br />
<br />
== Usage ==<br />
<br />
=== Starting Unbound ===<br />
<br />
The ''unbound'' package provides {{ic|unbound.service}}, just [[start]] it. You may want to ''enable'' it so that it starts at boot.<br />
<br />
=== Remotely control Unbound ===<br />
<br />
''unbound'' ships with the {{ic|unbound-control}} utility which enables us to remotely administer the unbound server. It is similar to the [[Pdnsd#pdnsd-ctl|pdnsd-ctl]] command of {{Pkg|pdnsd}}.<br />
<br />
==== Setting up unbound-control ====<br />
<br />
Before you can start using it, the following steps need to be performed:<br />
<br />
1) Firstly, you need to run the following command<br />
<br />
# unbound-control-setup<br />
<br />
which will generate a self-signed certificate and private key for the server, as well as the client. These files will be created in the {{ic|/etc/unbound}} directory.<br />
<br />
2) After that, edit {{ic|/etc/unbound/unbound.conf}} and put the following contents in that. The '''control-enable: yes''' option is necessary, the rest can be adjusted as required.<br />
<br />
remote-control:<br />
# Enable remote control with unbound-control(8) here.<br />
# set up the keys and certificates with unbound-control-setup.<br />
control-enable: yes<br />
<br />
# what interfaces are listened to for remote control.<br />
# give 0.0.0.0 and ::0 to listen to all interfaces.<br />
control-interface: 127.0.0.1<br />
<br />
# port number for remote control operations.<br />
control-port: 8953<br />
<br />
# unbound server key file.<br />
server-key-file: "/etc/unbound/unbound_server.key"<br />
<br />
# unbound server certificate file.<br />
server-cert-file: "/etc/unbound/unbound_server.pem"<br />
<br />
# unbound-control key file.<br />
control-key-file: "/etc/unbound/unbound_control.key"<br />
<br />
# unbound-control certificate file.<br />
control-cert-file: "/etc/unbound/unbound_control.pem"<br />
<br />
==== Using unbound-control ====<br />
<br />
Some of the commands that can be used with ''unbound-control'' are:<br />
<br />
* print statistics without resetting them<br />
# unbound-control stats_noreset<br />
<br />
* dump cache to stdout<br />
# unbound-control dump_cache<br />
<br />
* flush cache and reload configuration<br />
# unbound-control reload<br />
<br />
Please refer to {{ic|man 8 unbound-control}} for a detailed look at the operations it supports.<br />
<br />
== Adding an authoritative DNS server ==<br />
<br />
For users who wish to run both a validating, recursive, caching DNS server as well as an authoritative DNS server on a single machine then it may be useful to refer to the wiki page [[nsd]] which gives an example of a configuration for such a system. Having one server for authoritative DNS queries and a separate DNS server for the validating, recursive, caching DNS functions gives increased security over a single DNS server providing all of these functions. Many users have used bind as a single DNS server, and some help on migration from bind to the combination of running nsd and bind is provided in the [[nsd]] wiki page.<br />
<br />
== WAN facing DNS ==<br />
<br />
It is also possible to change the configuration files and interfaces on which the server is listening so that DNS queries from machines outside of the local network can access specific machines within the LAN. This is useful for web and mail servers which are accessible from anywhere, and the same techniques can be employed as has been achieved using bind for many years, in combination with suitable port forwarding on firewall machines to forward incoming requests to the right machine.<br />
<br />
== Issues concerning num-threads ==<br />
<br />
The man page for {{ic|unbound.conf}} mentions:<br />
<br />
outgoing-range: <number><br />
Number of ports to open. This number of file descriptors can be opened per thread.<br />
<br />
and some sources suggest that the {{ic|num-threads}} parameter should be set to the number of cpu cores. The sample {{ic|unbound.conf.example}} file merely has:<br />
<br />
# number of threads to create. 1 disables threading.<br />
# num-threads: 1<br />
<br />
However it is not possible to arbitrarily increase {{ic|num-threads}} above {{ic|1}} without causing ''unbound'' to start with warnings in the logs about exceeding the number of file descriptors. In reality for most users running on small networks or on a single machine it should be unnecessary to seek performance enhancement by increasing {{ic|num-threads}} above {{ic|1}}. If you do wish to do so then refer to [http://www.unbound.net/documentation/howto_optimise.html official documentation] and the following rule of thumb should work:<br />
<br />
:''Set {{ic|num-threads}} equal to the number of CPU cores on the system. E.g. for 4 CPUs with 2 cores each, use 8.''<br />
<br />
Set the {{ic|outgoing-range}} to as large a value as possible, see the sections in the referred web page above on how to overcome the limit of {{ic|1024}} in total. This services more clients at a time. With 1 core, try {{ic|950}}. With 2 cores, try {{ic|450}}. With 4 cores try {{ic|200}}. The {{ic|num-queries-per-thread}} is best set at half the number of the {{ic|outgoing-range}}. <br />
<br />
Because of the limit on {{ic|outgoing-range}} thus also limits {{ic|num-queries-per-thread}}, it is better to compile with {{Pkg|libevent}}, so that there is no {{ic|1024}} limit on {{ic|outgoing-range}}. If you need to compile this way for a heavy duty DNS server then you will need to compile the programme from source instead of using the {{Pkg|unbound}} package.<br />
<br />
== Block advertising ==<br />
You can use the following file and simply include it in your unbound configuration: [https://pgl.yoyo.org/adservers/serverlist.php?hostformat=unbound&showintro=0&startdate%5Bday%5D=&startdate%5Bmonth%5D=&startdate%5Byear%5D=&mimetype=plaintext adservers]<br />
{{hc|/etc/unbound/unbound.conf|<br />
...<br />
include: /etc/unbound/adservers<br />
}}<br />
<br />
{{Note|In order to return some OK statuses on those hosts, you can change the 127.0.0.1 redirection to a server you control and have that server respond with empty 204 replies, see [http://www.shadowandy.net/2014/04/adblocking-nginx-serving-1-pixel-gif-204-content.htm this page]}}<br />
<br />
=== See also ===<br />
<br />
* [https://github.com/jodrell/unbound-block-hosts/ Block hosts that contain advertisements]</div>Moviurohttps://wiki.archlinux.org/index.php?title=Unbound&diff=420988Unbound2016-02-16T20:58:19Z<p>Moviuro: /* See also */ -> /* Block advertising */</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[ja:Unbound]]<br />
[[zh-cn:Unbound]]<br />
[https://unbound.net/ Unbound] is a validating, recursive, and caching DNS resolver.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|unbound}} package from [[official repositories]].<br />
<br />
Additionally, {{Pkg|expat}} is required for [[DNSSEC]] validation.<br />
<br />
== Configuration ==<br />
<br />
''unbound'' is easy to configure. There is a sample config file {{ic|/etc/unbound/unbound.conf.example}}, which can be copied to {{ic|/etc/unbound/unbound.conf}} and with the adjustments to the file for your own needs it is enough to run on both IPv4 and IPv6 without access restrictions.<br />
<br />
=== Access control ===<br />
<br />
You can specify the interfaces to answer queries from by IP address. To listen on ''localhost'', use:<br />
<br />
interface: 127.0.0.1<br />
<br />
To listen on all interfaces, use:<br />
<br />
interface: 0.0.0.0<br />
<br />
Access can be further configured via the {{ic|access-control}} option:<br />
<br />
access-control: ''subnet'' ''action''<br />
<br />
For example:<br />
<br />
access-control: 192.168.1.0/24 allow<br />
<br />
''action'' can be one of {{ic|deny}} (drop message), {{ic|refuse}} (polite error reply), {{ic|allow}} (recursive ok), or {{ic|allow_snoop}} (recursive and nonrecursive ok). By default everything is refused except for localhost.<br />
<br />
=== Root hints ===<br />
<br />
For querying a host that is not cached as an address the resolver needs to start at the top of the server tree and query the root servers to know where to go for the top level domain for the address being queried. Therefore it is necessary to put a ''root hints'' file into the ''unbound'' config directory. The simplest way to do this is to run the command:<br />
<br />
{{bc|<nowiki># curl -o /etc/unbound/root.hints https://www.internic.net/domain/named.cache</nowiki>}}<br />
<br />
It is a good idea to run this every six months or so in order to make sure the list of root servers is up to date. This can be done manually or by setting up a [[cron]] job for the task.<br />
<br />
Point ''unbound'' to the {{ic|root.hints}} file:<br />
<br />
root-hints: "/etc/unbound/root.hints"<br />
<br />
=== Set /etc/resolv.conf to use the local DNS server ===<br />
<br />
Edit {{ic|/etc/resolv.conf}} (See also [[resolv.conf]]):<br />
<br />
nameserver 127.0.0.1<br />
<br />
Also if you want to be able to use the hostname of local machine names without the fully qualified domain names, then add a line with the local domain such as:<br />
<br />
domain localdomain.com<br />
nameserver 127.0.0.1<br />
<br />
That way you can refer to local hosts such as mainmachine1.localdomain.com as simply mainmachine1 when using the ssh command, but the drill command below still requires the fully qualified domain names in order to perform lookups.<br />
<br />
Testing the server before making it default can be done using the drill command from the {{Pkg|ldns}} package with examples from internal and external forward and reverse addresses:<br />
<br />
$ drill @127.0.0.1 www.cnn.com<br />
$ drill @127.0.0.1 localmachine.localdomain.com<br />
$ drill @127.0.0.1 -x w.x.y.z <br />
<br />
where {{ic|w.x.y.z}} can be a local or external IP address and the {{ic|-x}} option requests a reverse lookup. Once all is working, and you have {{ic|/etc/resolv.conf}} set to use {{ic|127.0.0.1}} as the nameserver then you no longer need the {{ic|@127.0.0.1}} in the ''drill'' command, and you can test again that it uses the default DNS server - check that the server used as listed at the bottom of the output from each of these commands shows it is {{ic|127.0.0.1}} being queried.<br />
<br />
=== Logging ===<br />
<br />
If you will want logging for ''unbound'', then create a log file which can also be in the same directory, but you can choose any location. One way is then to do as root:<br />
<br />
# touch /etc/unbound/unbound.log<br />
# chown unbound:unbound /etc/unbound/unbound.log<br />
<br />
Then you can include the logging parameter when you set up the main {{ic|unbound.conf}} file as below.<br />
<br />
=== DNSSEC validation ===<br />
<br />
You will need the root server trust key anchor file. It is provided by the {{Pkg|dnssec-anchors}} package (already installed as a dependency), however, ''unbound'' needs read and write access to the file. The {{ic|unbound.service}} service accomplishes this by copying the {{ic|/etc/trusted-key.key}} file to {{ic|/etc/unbound/trusted-key.key}}. You just need to point ''unbound'' to this file:<br />
{{hc|/etc/unbound/unbound.conf|<br />
server:<br />
...<br />
trust-anchor-file: trusted-key.key<br />
...<br />
}}<br />
<br />
Also make sure that if a general [[#Forwarding queries|forward]] to the Google servers had been in place, then comment them out otherwise DNS queries will fail. DNSSEC validation will be done if the DNS server being queried supports it.<br />
<br />
{{Note|Including DNSSEC checking significantly increases DNS lookup times for initial lookups. Once an address is cached locally, then the lookup is virtually instantaneous.}}<br />
<br />
You can now test if DNSSEC is working, using ''drill'' in {{Pkg|ldns}} (installed as dependency):<br />
<br />
drill sigfail.verteiltesysteme.net # should return rcode: SERVFAIL<br />
drill sigok.verteiltesysteme.net # should return rcode: NOERROR<br />
<br />
=== Forwarding queries ===<br />
<br />
If you have a local network which you wish to have DNS queries for and there is a local DNS server that you would like to forward queries to then you should include this line:<br />
<br />
private-address: ''local_subnet/subnet_mask''<br />
<br />
for example:<br />
<br />
private-address: 10.0.0.0/24<br />
<br />
{{note|You can use private-address to protect against DNS Rebind attacks. Therefore you may enable RFC1918 networks (10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16 fd00::/8 fe80::/10). Unbound may enable this feature by default in future releases.}} <br />
<br />
To include a local DNS server for both forward and reverse local addresses a set of lines similar to these below is necessary with a forward and reverse lookup (choose the IP address of the server providing DNS for the local network accordingly by changing 10.0.0.1 in the lines below):<br />
<br />
local-zone: "10.in-addr.arpa." transparent<br />
<br />
This line above is important to get the reverse lookup to work correctly.<br />
<br />
forward-zone:<br />
name: "mynetwork.com."<br />
forward-addr: 10.0.0.1 # Home DNS<br />
<br />
forward-zone:<br />
name: "10.in-addr.arpa."<br />
forward-addr: 10.0.0.1<br />
<br />
{{Note|There is a difference between forward zones and stub zones - stub zones will only work when connected to an authoritative DNS server directly. This would work for lookups from a [[BIND]] DNS server if it is providing authoritative DNS - but if you are referring queries to an ''unbound'' server in which internal lookups are forwarded on to another DNS server, then defining the referral as a stub zone in the machine here will not work. In that case it is necessary to define a forward zone as above, since forward zones can have daisy chain lookups onward to other DNS servers. i.e. forward zones can refer queries to recursive DNS servers. This distinction is important as you do not get any error messages indicating what the problem is if you use a stub zone inappropriately.}}<br />
<br />
You can set up the localhost forward and reverse lookups with the following lines:<br />
<br />
local-zone: "localhost." static<br />
local-data: "localhost. 10800 IN NS localhost."<br />
local-data: "localhost. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"<br />
local-data: "localhost. 10800 IN A 127.0.0.1"<br />
local-zone: "127.in-addr.arpa." static<br />
local-data: "127.in-addr.arpa. 10800 IN NS localhost."<br />
local-data: "127.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 2 3600 1200 604800 10800"<br />
local-data: "1.0.0.127.in-addr.arpa. 10800 IN PTR localhost."<br />
<br />
Then to use specific servers for default forward zones that are outside of the local machine and outside of the local network (i.e. all other queries will be forwarded to them, and then cached) add this to the configuration file (and in this example the first two addresses are the fast google DNS servers):<br />
<br />
forward-zone:<br />
name: "."<br />
forward-addr: 8.8.8.8<br />
forward-addr: 8.8.4.4<br />
forward-addr: 208.67.222.222<br />
forward-addr: 208.67.220.220<br />
<br />
This will make ''unbound'' use Google and OpenDNS servers as the forward zone for external lookups.<br />
<br />
{{Note|OpenDNS strips DNSSEC records from responses. Do not use the above forward zone if you want to enable [[#DNSSEC validation]].}}<br />
<br />
== Usage ==<br />
<br />
=== Starting Unbound ===<br />
<br />
The ''unbound'' package provides {{ic|unbound.service}}, just [[start]] it. You may want to ''enable'' it so that it starts at boot.<br />
<br />
=== Remotely control Unbound ===<br />
<br />
''unbound'' ships with the {{ic|unbound-control}} utility which enables us to remotely administer the unbound server. It is similar to the [[Pdnsd#pdnsd-ctl|pdnsd-ctl]] command of {{Pkg|pdnsd}}.<br />
<br />
==== Setting up unbound-control ====<br />
<br />
Before you can start using it, the following steps need to be performed:<br />
<br />
1) Firstly, you need to run the following command<br />
<br />
# unbound-control-setup<br />
<br />
which will generate a self-signed certificate and private key for the server, as well as the client. These files will be created in the {{ic|/etc/unbound}} directory.<br />
<br />
2) After that, edit {{ic|/etc/unbound/unbound.conf}} and put the following contents in that. The '''control-enable: yes''' option is necessary, the rest can be adjusted as required.<br />
<br />
remote-control:<br />
# Enable remote control with unbound-control(8) here.<br />
# set up the keys and certificates with unbound-control-setup.<br />
control-enable: yes<br />
<br />
# what interfaces are listened to for remote control.<br />
# give 0.0.0.0 and ::0 to listen to all interfaces.<br />
control-interface: 127.0.0.1<br />
<br />
# port number for remote control operations.<br />
control-port: 8953<br />
<br />
# unbound server key file.<br />
server-key-file: "/etc/unbound/unbound_server.key"<br />
<br />
# unbound server certificate file.<br />
server-cert-file: "/etc/unbound/unbound_server.pem"<br />
<br />
# unbound-control key file.<br />
control-key-file: "/etc/unbound/unbound_control.key"<br />
<br />
# unbound-control certificate file.<br />
control-cert-file: "/etc/unbound/unbound_control.pem"<br />
<br />
==== Using unbound-control ====<br />
<br />
Some of the commands that can be used with ''unbound-control'' are:<br />
<br />
* print statistics without resetting them<br />
# unbound-control stats_noreset<br />
<br />
* dump cache to stdout<br />
# unbound-control dump_cache<br />
<br />
* flush cache and reload configuration<br />
# unbound-control reload<br />
<br />
Please refer to {{ic|man 8 unbound-control}} for a detailed look at the operations it supports.<br />
<br />
== Adding an authoritative DNS server ==<br />
<br />
For users who wish to run both a validating, recursive, caching DNS server as well as an authoritative DNS server on a single machine then it may be useful to refer to the wiki page [[nsd]] which gives an example of a configuration for such a system. Having one server for authoritative DNS queries and a separate DNS server for the validating, recursive, caching DNS functions gives increased security over a single DNS server providing all of these functions. Many users have used bind as a single DNS server, and some help on migration from bind to the combination of running nsd and bind is provided in the [[nsd]] wiki page.<br />
<br />
== WAN facing DNS ==<br />
<br />
It is also possible to change the configuration files and interfaces on which the server is listening so that DNS queries from machines outside of the local network can access specific machines within the LAN. This is useful for web and mail servers which are accessible from anywhere, and the same techniques can be employed as has been achieved using bind for many years, in combination with suitable port forwarding on firewall machines to forward incoming requests to the right machine.<br />
<br />
== Issues concerning num-threads ==<br />
<br />
The man page for {{ic|unbound.conf}} mentions:<br />
<br />
outgoing-range: <number><br />
Number of ports to open. This number of file descriptors can be opened per thread.<br />
<br />
and some sources suggest that the {{ic|num-threads}} parameter should be set to the number of cpu cores. The sample {{ic|unbound.conf.example}} file merely has:<br />
<br />
# number of threads to create. 1 disables threading.<br />
# num-threads: 1<br />
<br />
However it is not possible to arbitrarily increase {{ic|num-threads}} above {{ic|1}} without causing ''unbound'' to start with warnings in the logs about exceeding the number of file descriptors. In reality for most users running on small networks or on a single machine it should be unnecessary to seek performance enhancement by increasing {{ic|num-threads}} above {{ic|1}}. If you do wish to do so then refer to [http://www.unbound.net/documentation/howto_optimise.html official documentation] and the following rule of thumb should work:<br />
<br />
:''Set {{ic|num-threads}} equal to the number of CPU cores on the system. E.g. for 4 CPUs with 2 cores each, use 8.''<br />
<br />
Set the {{ic|outgoing-range}} to as large a value as possible, see the sections in the referred web page above on how to overcome the limit of {{ic|1024}} in total. This services more clients at a time. With 1 core, try {{ic|950}}. With 2 cores, try {{ic|450}}. With 4 cores try {{ic|200}}. The {{ic|num-queries-per-thread}} is best set at half the number of the {{ic|outgoing-range}}. <br />
<br />
Because of the limit on {{ic|outgoing-range}} thus also limits {{ic|num-queries-per-thread}}, it is better to compile with {{Pkg|libevent}}, so that there is no {{ic|1024}} limit on {{ic|outgoing-range}}. If you need to compile this way for a heavy duty DNS server then you will need to compile the programme from source instead of using the {{Pkg|unbound}} package.<br />
<br />
== Block advertising ==<br />
You can use the following file and simply include it in your unbound configuration: https://pgl.yoyo.org/adservers/serverlist.php?hostformat=unbound&showintro=0&startdate%5Bday%5D=&startdate%5Bmonth%5D=&startdate%5Byear%5D=&mimetype=plaintext<br />
{{hc|/etc/unbound/unbound.conf|<br />
...<br />
include: /etc/unbound/adservers<br />
}}<br />
<br />
{{Note|In order to return some OK statuses on those hosts, you can change the 127.0.0.1 redirection to a server you control and have that server respond with empty 204 replies, see http://www.shadowandy.net/2014/04/adblocking-nginx-serving-1-pixel-gif-204-content.htm}}<br />
<br />
=== See also ===<br />
<br />
* [https://github.com/jodrell/unbound-block-hosts/ Block hosts that contain advertisements]</div>Moviurohttps://wiki.archlinux.org/index.php?title=Unison&diff=419614Unison2016-02-08T15:05:35Z<p>Moviuro: /* Version incompatibility */ + OCaml version must be the same, too.</p>
<hr />
<div>[[Category:Internet applications]]<br />
[[de:Unison]]<br />
[[zh-CN:Unison]]<br />
'''Unison''' is a bidirectional file synchronization tool that runs on Unix-like operating systems (including Linux, Mac OS X, and Solaris) and Windows. It allows two replicas of a collection of files and directories to be stored on different hosts (or different disks on the same host), modified separately, and then brought up to date by propagating the changes in each replica to the other. It also unrestricted in terms of which system can be the host.<br />
<br />
== Installation ==<br />
<br />
[[Installing]] {{Pkg|unison}} from the [[official repositories]], which provides CLI, GTK+ and GTK+ 2.0 interfaces. For offline documentation install {{AUR|unison-doc}}{{Broken package link|{{aur-mirror|unison-doc}}}} from the [[AUR]].<br />
<br />
== Configuration ==<br />
<br />
In order to use Unison, you need to create a profile.<br />
<br />
=== GUI ===<br />
<br />
To configure Unison with the GUI run:<br />
$ unison-gtk2<br />
<br />
=== Manual ===<br />
<br />
Alternatively, manually create a profile in {{ic|~/.unison}} and add the following lines to the default configuration file, {{ic|~/.unison/''profilename''.prf}}.<br />
<br />
Define the root directory to be synchronized.<br />
root=/home/user/<br />
<br />
Define the remote directory where the files should be sychronized to.<br />
root=ssh://example.com//path/to/server/storags<br />
<br />
Optionally, provide arguments to [[SSH]].<br />
sshargs=-p 4000<br />
<br />
Define which directories and files should be synchronized:<br />
# dirs<br />
path=Documents<br />
path=Photos<br />
path=Study<br />
# files<br />
path=.bashrc<br />
path=.vimrc<br />
<br />
You can also define which files to ignore:<br />
ignore=Name temp.*<br />
ignore=Name .*~<br />
ignore=Name *.tmp<br />
<br />
{{note|For more information see the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#profileegs Sample profiles] in the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html User Manual and Reference Guide].}}<br />
<br />
== Usage ==<br />
<br />
Once your profile is set up, you can start syncing:<br />
$ unison ''profilename''<br />
or using the GUI tool:<br />
$ unison-gtk2<br />
and select the profile. Unison has a nice interface where you can view the progress and changes.<br />
<br />
== Version incompatibility ==<br />
<br />
For Unison to function properly, the same version ''must'' be installed on all clients. If, for example, one computer has version 2.40 and the other has 2.32, they will not be able to sync with each other. This applies to ''all'' computers that share a directory to be synchronized across your machines.<br />
<br />
The Unison binary/ies also ''must'' be compiled against the same version of OCaml, see https://groups.yahoo.com/neo/groups/unison-users/conversations/topics/11439 . This makes Unison virtualy unusable on heterogeneous networks.<br />
<br />
Due to the staggered releases with varying Linux distros, you might be stuck with older versions of Unison, while Arch Linux has the latest upstream version in the Extra repository. There are unofficial [[PKGBUILD]]s for versions 2.32 ({{AUR|unison-232}}{{Broken package link|{{aur-mirror|unison-232}}}}) and 2.27 ({{AUR|unison-227}}{{Broken package link|{{aur-mirror|unison-227}}}}) on the [[AUR]] that allow users of multiple distros to continue using Unison with their existing systems.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Save human time and keystrokes ===<br />
<br />
If one runs unison within a terminal emulator capable of maintaining a suitable scrollback buffer, there is no purpose in having to confirm every non-conflicting change; set the {{ic|auto}} option to true to avoid these prompts.<br />
<br />
=== More helpful diff output ===<br />
<br />
The unison default diff command is {{ic|diff -u CURRENT2 CURRENT1}}. When looking at the output of this command, it can be difficult to remember which changes will be kept when propagating from left to right ('>'), versus right to left ('<'). The following configuration makes it easy to remember: '>' keeps lines which start with '>':<br />
<br />
diff = diff -u CURRENT2 CURRENT1 | perl -pe 's/^\+/>/; s/^\-/</'<br />
<br />
=== Merging in Emacs ===<br />
<br />
Unison has the capability to assist users in merging two conflicting files using an external merge program, but it does not configure such a program by default. The manual suggests<br />
<br />
merge = Name *.txt -> emacs -q --eval '(ediff-merge-files-with-ancestor "CURRENT1" "CURRENT2" "CURRENTARCH" nil "NEW")'<br />
<br />
This assumes that you are running Unison in X, because the merge command cannot be run in the terminal (Emacs: "standard input is not a tty"). Note also that Unison replaces the CURRENT1, etc., variables with single-quoted filenames. Thus, the above works, but using double quotes throughout, as in "(ediff-merge-files... \"CURRENT1\" ...)", would not work.<br />
<br />
Using the variable CURRENTARCH tells Unison that you expect to do 3-way merges with a common ancestor, which is only possible if the "backupcurrent" preference has been set previously to the last sync. To perform an ordinary 2-way merge in a terminal, one could use the following configuration instead. This also uses emerge.el, which some find preferable to ediff.el:<br />
<br />
merge = Name {*,.*} -> urxvt -e emacs -nw -q --eval '(emerge-files nil "CURRENT1" "CURRENT2" "NEW")'<br />
<br />
If the variable CURRENTARCHOPT is used instead of CURRENTARCH, then Unison will provide a common ancestor when it is available, and otherwise fall back to requesting a 2-way merge (by setting the variable to the empty string). This can be detected in a shell script. For example:<br />
<br />
merge = Name {*,.*} -> unison-merge-files CURRENT1 CURRENT2 NEW CURRENTARCHOPT<br />
<br />
with {{ic|unison-merge-files}} defined as follows:<br />
<br />
#!/bin/sh<br />
CURRENT1=$1<br />
CURRENT2=$2<br />
NEW=$3<br />
CURRENTARCHOPT=$4<br />
EMACS="urxvt -e emacs -nw"<br />
if [ x$CURRENTARCHOPT = x ]; then<br />
$EMACS --eval "(emerge-files nil \"$CURRENT1\" \"$CURRENT2\" \"$NEW\")";<br />
else<br />
$EMACS --eval "(emerge-files-with-ancestor nil \"$CURRENT1\" \"$CURRENT2\" \"$CURRENTARCHOPT\" \"$NEW\")";<br />
fi<br />
<br />
<br />
=== Common config sync ===<br />
<br />
When syncing configuration files which would vary (e.g., due to endemic applications, security-sensitive configuration) among systems (servers, workstations, laptops, smartphones, etc.) but nevertheless contain common constructs (e.g., key bindings, basic shell aliases), it would be apt to separate such content into separate config files (e.g., {{ic|.bashrc_common}}), and sync only these.<br />
<br />
{{Warning|Bidirectional syncing of config files can lend itself to become an avenue for an attack, by enabling the peer syncing system to receive malicious changes to config files (and perhaps even other peers the system syncs with). This is an attractive option for adversaries, especially when the conceptual security levels of the two systems differ (e.g., public shell server vs. personal workstation), since it would likely be simpler to compromise a system of lower security. Always use the {{ic|noupdate}} option when bidirectional syncing between two particular systems is deemed unnecessary; when necessary, verify each change when syncing. Automatic bidirectional syncs should be done with extreme caution.}}<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:Unison (file synchronizer)]]<br />
* [http://www.cis.upenn.edu/~bcpierce/unison/ Official website]<br />
* [http://tech.groups.yahoo.com/group/unison-users Yahoo! user group]<br />
* ''[http://www.pgbovine.net/unison_guide.htm Liberation through data replication]'' by Philip Guo<br />
* ''[http://www.pgbovine.net/unison-for-your-mom.htm Setting up Unison for your mom]'' by Philip Guo<br />
* ''[http://twiki.org/cgi-bin/view/Codev/ReplicationUsingUnison Replication using Unison]'' on TWiki</div>Moviurohttps://wiki.archlinux.org/index.php?title=Systemd-networkd&diff=415979Systemd-networkd2016-01-17T20:32:04Z<p>Moviuro: /* IPv6 privacy extensions */ broken on v228</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Network configuration]]<br />
[[Category:Virtualization]]<br />
[[es:Systemd-networkd]]<br />
[[fr:systemd-networkd]]<br />
[[ja:systemd-networkd]]<br />
[[ru:Systemd-networkd]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|systemd-nspawn}}<br />
{{Related|Network bridge}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related|:Category:Network managers}}<br />
{{Related articles end}}<br />
<br />
''systemd-networkd'' is a system daemon that manages network configurations. It detects and configures network devices as they appear; it can also create virtual network devices. This service can be especially useful to set up complex network configurations for a container managed by [[systemd-nspawn]] or for virtual machines. It also works fine on simple connections.<br />
<br />
== Basic usage ==<br />
The {{Pkg|systemd}} package is part of the default Arch installation and contains all needed files to operate a wired network. Wireless adapters can be setup by other services, such as [[wpa_supplicant]], which are covered later in this article.<br />
<br />
=== Required services and setup ===<br />
<br />
To use ''systemd-networkd'', [[start]] the following two services and [[enable]] them to run on system boot:<br />
<br />
* {{ic|systemd-networkd.service}}<br />
* {{ic|systemd-resolved.service}}<br />
<br />
{{Note|''systemd-resolved'' is actually required only if you are specifying DNS entries in ''.network'' files or if you want to obtain DNS addresses from networkd's DHCP client.}}<br />
<br />
For compatibility with [[resolv.conf]], delete or rename the existing file and create the following symbolic link:<br />
<br />
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
<br />
Optionally, if you wish to use the local DNS stub resolver of ''systemd-resolved'' (and thus use LLMNR and DNS merging per interface), replace {{ic|dns}} with {{ic|resolve}} in {{ic|/etc/nsswitch.conf}}:<br />
<br />
hosts: files '''resolve''' myhostname<br />
<br />
See {{ic|man systemd-resolved}} and {{ic|man resolved.conf}} and [https://github.com/systemd/systemd/blob/master/README#L205 Systemd README].<br />
<br />
{{Note|Systemd's {{ic|resolve}} may not search the local domain when given just the hostname, even when {{ic|1=UseDomains=yes}} or {{ic|1=Domains=[domain-list]}} is present in the appropriate {{ic|.network}} file, and that file produces the expected {{ic|search [domain-list]}} in {{ic|resolv.conf}}. If you run into this problem:<br />
* Switch to using fully-qualified domain names<br />
* Use {{ic|/etc/hosts}} to resolve hostnames<br />
* Fall back to using glibc's {{ic|dns}} instead of using systemd's {{ic|resolve}}}}<br />
<br />
=== Configuration examples ===<br />
All configurations in this section are stored as {{ic|foo.network}} in {{ic|/etc/systemd/network}}. For a full listing of options and processing order, see [[#Configuration files]] and the {{ic|systemd.network}} man page.<br />
<br />
Systemd/udev automatically assigns predictable, stable network interface names for all local Ethernet, WLAN, and WWAN interfaces. Use {{ic|networkctl list}} to list the devices on the system.<br />
<br />
After making changes to a configuration file, reload the networkd daemon.<br />
<br />
# systemctl restart systemd-networkd <br />
<br />
{{Note|In the examples below, '''enp1s0''' is the wired adapter and '''wlp2s0''' is the wireless adapter. These names can be different on different systems.}}<br />
<br />
==== Wired adapter using DHCP ====<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
DHCP=ipv4</nowiki><br />
}}<br />
<br />
==== Wired adapter using a static IP ====<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
Address=10.1.10.9/24<br />
Gateway=10.1.10.1</nowiki><br />
}}<br />
<br />
See the {{ic|systemd.network(5)}} man page for more network options such as specifying DNS servers and a broadcast address.<br />
<br />
==== Wireless adapter ====<br />
In order to connect to a wireless network with ''systemd-networkd'', a wireless adapter configured with another service such as [[wpa_supplicant]] is required. In this example, the corresponding systemd service file that needs to be enabled is {{ic|wpa_supplicant@wlp2s0.service}}.<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
If the wireless adapter has a static IP address, the configuration is the same (except for the interface name) as in a [[#Wired adapter using a static IP|wired adapter]].<br />
<br />
==== Wired and wireless adapters on the same machine ====<br />
<br />
This setup will enable a DHCP IP for both a wired and wireless connection making use of the metric directive to allow the kernel the decide on-the-fly which one to use. This way, no connection downtime is observed when the wired connection is unplugged.<br />
<br />
The kernel's route metric (same as configured with ''ip'') decides which route to use for outgoing packets, in cases when several match. This will be the case when both wireless and wired devices on the system have active connections. To break the tie, the kernel uses the metric. If one of the connections is terminated, the other automatically wins without there being a gap with nothing configured (ongoing transfers may still not deal with this nicely but that is at a different OSI layer).<br />
<br />
{{Note|The '''Metric''' option is for static routes while the '''RouteMetric''' option is for setups not using static routes.}}<br />
<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
<br />
[DHCP]<br />
RouteMetric=10<br />
</nowiki>}}<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
<br />
[DHCP]<br />
RouteMetric=20<br />
</nowiki>}}<br />
<br />
==== IPv6 privacy extensions ====<br />
<br />
{{Note|Broken on v228 https://github.com/systemd/systemd/issues/2242}}<br />
If you are using IPv6 you might also want to set the {{ic|IPv6PrivacyExtensions}} option as settings placed in {{ic|/etc/sysctl.d/40-ipv6.conf}} are not honored.<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=yes<br />
IPv6PrivacyExtensions=true<br />
<br />
[DHCP]<br />
RouteMetric=20<br />
</nowiki>}}<br />
<br />
== Configuration files ==<br />
<br />
Configuration files are located in {{ic|/usr/lib/systemd/network}}, the volatile runtime network directory {{ic|/run/systemd/network}} and, the local administration network directory {{ic|/etc/systemd/network}}. Files in {{ic|/etc/systemd/network}} have the highest priority.<br />
<br />
There are three types of configuration files. <br />
<br />
* '''.network''' files. They will apply a network configuration for a ''matching'' device<br />
* '''.netdev''' files. They will create a ''virtual network device'' for a ''matching'' environment<br />
* '''.link''' files. When a network device appears, [[udev]] will look for the first ''matching'' '''.link''' file<br />
<br />
They all follow the same rules: <br />
<br />
* If '''all''' conditions in the {{ic|[Match]}} section are matched, the profile will be activated<br />
* an empty {{ic|[Match]}} section means the profile will apply in any case (can be compared to the {{ic|*}} joker)<br />
* each entry is a key with the {{ic|1=NAME=VALUE}} syntax <br />
* all configuration files are collectively sorted and processed in lexical order, regardless of the directory in which they live<br />
* files with identical name replace each other<br />
<br />
{{Tip|<br />
* to override a system-supplied file in {{ic|/usr/lib/systemd/network}} in a permanent manner (i.e even after upgrade), place a file with same name in {{ic|/etc/systemd/network}} and symlink it to {{ic|/dev/null}}<br />
* the {{ic|*}} joker can be used in {{ic|VALUE}} (e.g {{ic|en*}} will match any Ethernet device)<br />
* following this [https://mailman.archlinux.org/pipermail/arch-general/2014-March/035381.html Arch-general thread], the best practice is to setup specific container network settings ''inside the container'' with '''networkd''' configuration files.<br />
}}<br />
<br />
=== network files ===<br />
<br />
These files are aimed at setting network configuration variables, especially for servers and containers.<br />
<br />
Below is a basic structure of a {{ic|''MyProfile''.network}} file:<br />
<br />
{{hc|/etc/systemd/network/''MyProfile''.network|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[Network]<br />
''a vertical list of keys''<br />
<br />
[Address]<br />
''a vertical list of keys''<br />
<br />
[Route]<br />
''a vertical list of keys''<br />
}}<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=Name=}} the device name (e.g Br0, enp4s0)<br />
* {{ic|1=Host=}} the machine hostname<br />
* {{ic|1=Virtualization=}} check whether the system is executed in a virtualized environment or not. A {{ic|1=Virtualization=no}} key will only apply on your host machine, while {{ic|1=Virtualization=yes}} apply to any container or VM.<br />
<br />
==== [Network] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=DHCP=}} enables [[Wikipedia:Dynamic Host Configuration Protocol|DHCPv4]] and/or DHCPv6 support. Accepts {{ic|yes}}, {{ic|no}}, {{ic|ipv4}} or {{ic|ipv6}}<br />
* {{ic|1=DNS=}} is a [[Wikipedia:Domain Name System|DNS]] server address. You can specify this option more than once<br />
* {{ic|1=Bridge=}} is the name of the bridge to add the link to<br />
* {{ic|1=IPForward=}} enables IP forwarding, performing the forwarding according to the routing table, and is required for setting up [[Internet sharing]]. Accepts {{ic|yes}}, {{ic|no}}, {{ic|ipv4}}, {{ic|ipv6}} or {{ic|kernel}}. Note that {{ic|1=IPForward}} defaults to 0, which means that if you do not specify a setting for {{ic|1=IPForward}} in your .network file, your interface will have IP forwarding turned off even if you turned it on with {{ic|sysctl}} or by writing into {{ic|/proc/sys}}.<br />
<br />
==== [Address] section ====<br />
Most common key in the {{ic|[Address]}} section is:<br />
<br />
* {{ic|1=Address=}} is a static '''IPv4''' or '''IPv6''' address and its prefix length, separated by a {{ic|/}} character (e.g {{ic|192.168.1.90/24}}). This option is '''mandatory''' unless DHCP is used.<br />
<br />
==== [Route] section ====<br />
Most common key in the {{ic|[Route]}} section is:<br />
<br />
* {{ic|1=Gateway=}} is the address of your machine gateway. This option is '''mandatory''' unless DHCP is used.<br />
For an exhaustive key list, please refer to {{ic|systemd.network(5)}}<br />
<br />
{{Tip|you can put the {{ic|1=Address=}} and {{ic|1=Gateway=}} keys in the {{ic|[Network]}} section as a short-hand if {{ic|1=Address=}} contains only an Address key and {{ic|1=Gateway=}} section contains only a Gateway key<br />
}}<br />
<br />
=== netdev files ===<br />
<br />
These files will create virtual network devices.<br />
<br />
Below is a basic structure of a ''Mydevice''.netdev file:<br />
<br />
{{hc|/etc/systemd/network/''MyDevice''.netdev|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[NetDev]<br />
''a vertical list of keys''<br />
}}<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are {{ic|1=Host=}} and {{ic|1=Virtualization=}}<br />
<br />
==== [NetDev] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=Name=}} is the interface name used when creating the netdev. This option is '''compulsory'''<br />
* {{ic|1=Kind=}} is the netdev kind. For example, ''bridge'', ''bond'', ''vlan'', ''veth'', ''sit'', etc. are supported. This option is '''compulsory'''<br />
<br />
For an exhaustive key list, please refer to {{ic|systemd.netdev(5)}}<br />
<br />
=== link files ===<br />
<br />
These files are an alternative to custom udev rules and will be applied by [[udev]] as the device appears.<br />
<br />
Below is a basic structure of a ''Mydevice''.link file:<br />
<br />
{{hc|/etc/systemd/network/''MyDevice''.link|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[Link]<br />
''a vertical list of keys''<br />
}}<br />
<br />
The {{ic|[Match]}} section will determine if a given link file may be applied to a given device, when the {{ic|[Link]}} section specifies the device configuration.<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are {{ic|1=MACAddress=}}, {{ic|1=Host=}} and {{ic|1=Virtualization=}}.<br />
<br />
{{ic|1=Type=}} is the device type (e.g. vlan)<br />
<br />
==== [Link] section ====<br />
<br />
Most common keys are:<br />
<br />
{{ic|1=MACAddressPolicy=}} is either ''persistent'' when the hardware has a persistent MAC address (as most hardware should) or ''random'' , which allows to give a random MAC address when the device appears.<br />
<br />
{{ic|1=MACAddress=}} shall be used when no {{ic|1=MACAddressPolicy=}} is specified.<br />
<br />
{{Note|the system {{ic|/usr/lib/systemd/network/99-default.link}} is generally sufficient for most of the basic cases.}}<br />
<br />
== Usage with containers ==<br />
<br />
The service is available with {{Pkg|systemd}} >= 210. You will want to [[systemd#Basic systemctl usage|enable and start]] the {{ic|systemd-networkd.service}} on the host and container.<br />
<br />
For debugging purposes, it is strongly advised to [[install]] the {{Pkg|bridge-utils}}, {{Pkg|net-tools}} and {{Pkg|iproute2}} packages.<br />
<br />
If you are using ''systemd-nspawn'', you may need to modify the {{ic|systemd-nspawn@.service}} and append boot options to the {{ic|ExecStart}} line. Please refer to {{ic|man 1 systemd-nspawn}} for an exhaustive list of options.<br />
<br />
Note that if you want to take advantage of automatic DNS configuration from DHCP, you need to enable {{ic|systemd-resolved}} and symlink {{ic|/run/systemd/resolve/resolv.conf}} to {{ic|/etc/resolv.conf}}. See {{ic|systemd-resolved.service(8)}} for more details.<br />
<br />
{{Style|Too many points for a tip, some of them are very similar so they could be merged.}}<br />
<br />
{{Tip|1=Before you start to configure your container network, it is useful to:<br />
* disable all your [[netctl]] services. This will avoid any potential conflicts with '''systemd-networkd''' and make all your configurations easier to test. Furthermore, odds are high you will end with few or even no [[netctl]] activated profiles. The {{ic|netctl list}} command will output a list of all your profiles, with the activated one being starred.<br />
* disable the {{ic|systemd-nspawn@.service}} and use the {{ic|systemd-nspawn -bnD /path_to/your_container/}} command as root to boot the container. To log off and shutdown inside the container {{ic|systemctl poweroff}} is used as root. Once the network setting meets your requirements, [[systemd#Basic systemctl usage|enable and start]] {{ic|systemd-nspawn@.service}}<br />
* disable the {{ic|dhcpcd.service}} if enabled on your system, since it activates ''dhcpcd'' on '''all''' interfaces<br />
* make sure you have no [[netctl]] profiles activated in the container, and ensure that {{ic|systemd-networkd.service}} is neither enabled nor started<br />
* make sure you do not have any [[iptables]] rules which can block traffic<br />
* make sure ''packet forwarding'' is [[Internet sharing#Enable packet forwarding|enabled]] if you want to let containers access the internet. Make sure that your .network file does not accidentally turn off forwarding because if you do not have a IPForward=1 setting in it, systemd-networkd will turn off forwarding on this interface, even if you have it enabled globally.<br />
* when the daemon is started the systemd {{ic|networkctl}} command displays the status of network interfaces.<br />
}}<br />
<br />
{{Note|For the set-up described below, <br />
* we will limit the output of the {{ic|ip a}} command to the concerned interfaces<br />
* we assume the ''host'' is your main OS you are booting to and the ''container'' is your guest virtual machine<br />
* all interface names and IP addresses are only examples<br />
}}<br />
<br />
=== Basic DHCP network ===<br />
<br />
This setup will enable a DHCP IP for host and container. In this case, both systems will share the same IP as they share the same interfaces.<br />
<br />
{{hc|/etc/systemd/network/''MyDhcp''.network|<nowiki><br />
[Match]<br />
Name=en*<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
Then, [[enable]] and start {{ic|systemd-networkd.service}} on your container.<br />
<br />
You can of course replace {{ic|en*}} by the full name of your ethernet device given by the output of the {{ic|ip link}} command.<br />
<br />
* on host and container:<br />
<br />
{{hc|$ ip a|<br />
2: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.72/24 brd 192.168.1.255 scope global enp7s0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
By default hostname received from the DHCP server will be used as the transient hostname.<br />
<br />
To change it add {{ic|1=UseHostname=false}} in section {{ic|[DHCPv4]}}<br />
{{hc|/etc/systemd/network/''MyDhcp''.network|<nowiki><br />
[DHCPv4]<br />
UseHostname=false<br />
</nowiki>}}<br />
<br />
If you did not want configure a DNS in {{ic|/etc/resolv.conf}} and want to rely on DHCP for setting it up, you need to [[enable]] {{ic|systemd-resolved.service}} and symlink {{ic|/run/systemd/resolve/resolv.conf}} to {{ic|/etc/resolv.conf}}<br />
<br />
# ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
<br />
See {{ic|systemd-resolved.service(8)}} for more details.<br />
<br />
=== DHCP with two distinct IP ===<br />
<br />
==== Bridge interface ====<br />
<br />
Create a virtual bridge interface <br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.netdev|<nowiki><br />
[NetDev]<br />
Name=br0<br />
Kind=bridge<br />
</nowiki>}}<br />
<br />
On host and container:<br />
<br />
{{hc|$ ip a|<br />
3: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default <br />
link/ether ae:bd:35:ea:0c:c9 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
Note that the interface br0 is listed but is DOWN.<br />
<br />
==== Bind ethernet to bridge ====<br />
<br />
Modify the {{ic|/etc/systemd/network/''MyDhcp''.network}} to remove the DHCP, as the bridge requires an interface to bind to with no IP, and add a key to bind this device to br0. Let us change its name to a more relevant one.<br />
<br />
{{hc|/etc/systemd/network/''MyEth''.network|<nowiki><br />
[Match]<br />
Name=en*<br />
<br />
[Network]<br />
Bridge=br0<br />
</nowiki>}}<br />
<br />
==== Bridge network ====<br />
<br />
Create a network profile for the Bridge<br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.network|<nowiki><br />
[Match]<br />
Name=br0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
==== Add option to boot the container ====<br />
<br />
As we want to give a separate IP for host and container, we need to ''Disconnect'' networking of the container from the host. To do this, add this option {{ic|1=--network-bridge=br0}} to your container boot command.<br />
<br />
# systemd-nspawn --network-bridge&#61;br0 -bD /path_to/my_container<br />
<br />
==== Result ====<br />
<br />
* on host<br />
<br />
{{hc|$ ip a|<br />
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default <br />
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.87/24 brd 192.168.1.255 scope global br0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link <br />
valid_lft forever preferred_lft forever<br />
6: vb-''MyContainer'': <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000<br />
link/ether d2:7c:97:97:37:25 brd ff:ff:ff:ff:ff:ff<br />
inet6 fe80::d07c:97ff:fe97:3725/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
* on container<br />
<br />
{{hc|$ ip a|<br />
2: host0: <BROADCAST,MULTICAST,ALLMULTI,AUTOMEDIA,NOTRAILERS,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
link/ether 5e:96:85:83:a8:5d brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.73/24 brd 192.168.1.255 scope global host0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5c96:85ff:fe83:a85d/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
==== Notice ====<br />
<br />
* we have now one IP address for Br0 on the host, and one for host0 in the container<br />
* two new interfaces have appeared: {{ic|vb-''MyContainer''}} in the host and {{ic|host0}} in the container. This comes as a result of the {{ic|1=--network-bridge=br0}} option. This option ''implies'' another option, {{ic|--network-veth}}. This means a ''virtual Ethernet link'' has been created between host and container.<br />
* the DHCP address on {{ic|host0}} comes from the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file.<br />
* on host<br />
<br />
{{hc|$ brctl show|<br />
bridge name bridge id STP enabled interfaces<br />
br0 8000.14dae9b57a88 no enp7s0<br />
vb-''MyContainer''<br />
}}<br />
<br />
the above command output confirms we have a bridge with two interfaces binded to.<br />
<br />
* on host<br />
<br />
{{hc|$ ip route|<br />
default via 192.168.1.254 dev br0 <br />
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.87<br />
}}<br />
<br />
* on container<br />
<br />
{{hc|$ ip route|<br />
default via 192.168.1.254 dev host0 <br />
192.168.1.0/24 dev host0 proto kernel scope link src 192.168.1.73<br />
}}<br />
<br />
the above command outputs confirm we have activated {{ic|br0}} and {{ic|host0}} interfaces with an IP address and Gateway 192.168.1.254. The gateway address has been automatically grabbed by ''systemd-networkd''<br />
<br />
{{hc|$ cat /run/systemd/resolve/resolv.conf|<br />
nameserver 192.168.1.254<br />
}}<br />
<br />
=== Static IP network ===<br />
<br />
Setting a static IP for each device can be helpful in case of deployed web services (e.g FTP, http, SSH). Each device will keep the same MAC address across reboots if your system {{ic|/usr/lib/systemd/network/99-default.link}} file has the {{ic|1=MACAddressPolicy=persistent}} option (it has by default). Thus, you will easily route any service on your Gateway to the desired device.<br />
First, we shall get rid of the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file. To do it in a permanent way (e.g even after upgrades), do the following on container. This will mask the file {{ic|/usr/lib/systemd/network/80-container-host0.network}} since files of the same name in {{ic|/etc/systemd/network}} take priority over {{ic|/usr/lib/systemd/network}}.<br />
<br />
# ln -sf /dev/null /etc/systemd/network/80-container-host0.network<br />
<br />
Then, [[systemd#Basic systemctl usage|enable and start]] {{ic|systemd-networkd}} on your container.<br />
<br />
The needed configuration files:<br />
* on host <br />
{{Accuracy|In the listing of configuration files, /etc/systemd/network/MyBridge.netdev has the .netdev extension. But, the MyBridge.network example file has the .network extension.}}<br />
<br />
/etc/systemd/network/''MyBridge''.netdev<br />
/etc/systemd/network/''MyEth''.network<br />
<br />
A modified ''MyBridge''.network<br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.network|<nowiki><br />
[Match]<br />
Name=br0<br />
<br />
[Network]<br />
DNS=192.168.1.254<br />
Address=192.168.1.87/24<br />
Gateway=192.168.1.254<br />
</nowiki>}}<br />
<br />
* on container<br />
<br />
{{hc|/etc/systemd/network/''MyVeth''.network|<nowiki><br />
[Match]<br />
Name=host0<br />
<br />
[Network]<br />
DNS=192.168.1.254<br />
Address=192.168.1.94/24<br />
Gateway=192.168.1.254<br />
</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html systemd.networkd man page]<br />
* [https://plus.google.com/u/0/+TomGundersen/posts Tom Gundersen, main systemd-networkd developer, G+ home page]<br />
* [https://coreos.com/blog/intro-to-systemd-networkd/ Tom Gundersen posts on Core OS blog]<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1393759#p1393759 How to set up systemd-networkd with wpa_supplicant] (WonderWoofy's walkthrough on Arch forums)</div>Moviurohttps://wiki.archlinux.org/index.php?title=IPv6&diff=415978IPv62016-01-17T20:31:29Z<p>Moviuro: /* Privacy extensions */ broken on v228</p>
<hr />
<div>[[Category:Networking]]<br />
[[es:IPv6]]<br />
[[ja:IPv6]]<br />
[[pt:IPv6]]<br />
[[ru:IPv6]]<br />
[[zh-CN:IPv6]]<br />
{{Related articles start}}<br />
{{Related|IPv6 tunnel broker setup}}<br />
{{Related articles end}}<br />
<br />
In Arch Linux, IPv6 is enabled by default.<br />
<br />
== Neighbor discovery ==<br />
<br />
Pinging the multicast address {{ic|ff02::1}} results in all hosts in link-local scope responding. An interface has to be specified:<br />
<br />
$ ping6 ff02::1%eth0<br />
<br />
With a ping to the multicast address {{ic|ff02::2}} only routers will respond.<br />
<br />
If you add an option {{ic|-I ''your-global-ipv6''}}, link-local hosts will respond with their link-global scope addresses. The interface can be omitted in this case:<br />
<br />
$ ping6 -I 2001:4f8:fff6::21 ff02::1<br />
<br />
== Stateless autoconfiguration (SLAAC) ==<br />
<br />
The easiest way to acquire an IPv6 address as long as your network is configured is through ''Stateless address autoconfiguration'' (SLAAC for short). The address is automatically inferred from the prefix that your router advertises and requires neither further configuration nor specialized software such as a DHCP client.<br />
<br />
=== For clients ===<br />
<br />
If you are using [[netctl]] you just need to add the following line to your ethernet or wireless configuration.<br />
<br />
IP6=stateless<br />
<br />
If you are using [[NetworkManager]] then it automatically enables IPv6 addresses if there are advertisements for them in the network.<br />
<br />
Please note that stateless autoconfiguration works on the condition that IPv6 icmp packets are allowed throughout the network. So for the client side the {{ic|ipv6-icmp}} packets must be accepted. If you are using the [[Simple stateful firewall]]/[[iptables]] you only need to add:<br />
<br />
-A INPUT -p ipv6-icmp -j ACCEPT<br />
<br />
If you are using an other firewall frontend (ufw, shorewall, etc) consult their documentation on how to enable the {{ic|ipv6-icmp}} packets.<br />
<br />
=== For gateways ===<br />
<br />
To properly hand out IPv6s to the network clients we will need to use an advertising daemon. The standard tool for this job is {{Pkg|radvd}} and is available in [[official repositories]]. Configuration of radvd is fairly simple. Edit {{ic|/etc/radvd.conf}} to include<br />
<br />
# replace LAN with your LAN facing interface<br />
interface LAN {<br />
AdvSendAdvert on;<br />
MinRtrAdvInterval 3;<br />
MaxRtrAdvInterval 10;<br />
prefix ::/64 {<br />
AdvOnLink on;<br />
AdvAutonomous on;<br />
AdvRouterAddr on;<br />
};<br />
};<br />
<br />
The above configuration will tell clients to autoconfigure themselves using addresses from the advertised /64 block. Please note that the above configuration advertises ''all available prefixes'' assigned to the LAN facing interface. If you want to limit the advertised prefixes instead of {{ic|::/64}} use the desired prefix, eg {{ic|2001:DB8::/64}}. The {{ic|prefix}} block can be repeated many times for more prefixes.<br />
<br />
The gateway must also allow the traffic of {{ic|ipv6-icmp}} packets on all basic chains. For the [[Simple stateful firewall]]/[[iptables]] add:<br />
<br />
-A INPUT -p ipv6-icmp -j ACCEPT<br />
-A OUTPUT -p ipv6-icmp -j ACCEPT<br />
-A FORWARD -p ipv6-icmp -j ACCEPT<br />
<br />
Adjust accordingly for other firewall frontends and do not forget to enable {{ic|radvd.service}}.<br />
<br />
== Privacy extensions ==<br />
{{Note|Broken on v228 https://github.com/systemd/systemd/issues/2242}}<br />
When a client acquires an address through SLAAC its IPv6 address is derived from the advertised prefix and the MAC address of the network interface of the client. This may raise security concerns as the MAC address of the computer can be easily derived by the IPv6 address. In order to tackle this problem the ''IPv6 Privacy Extensions'' standard ([https://tools.ietf.org/html/rfc4941 RFC 4941]) has been developed. With privacy extensions the kernel generates a ''temporary'' address that is mangled from the original autoconfigured address. Private addresses are preferred when connecting to a remote server so the original address is hidden. To enable Privacy Extensions reproduce the following steps:<br />
<br />
Add these lines to {{ic|/etc/sysctl.d/40-ipv6.conf}}:<br />
<br />
# Enable IPv6 Privacy Extensions<br />
net.ipv6.conf.all.use_tempaddr = 2<br />
net.ipv6.conf.default.use_tempaddr = 2<br />
net.ipv6.conf.''nic0''.use_tempaddr = 2<br />
...<br />
net.ipv6.conf.''nicN''.use_tempaddr = 2<br />
<br />
Where {{ic|nic0}} to {{ic|nicN}} are your '''N'''etwork '''I'''nterface '''C'''ards. The {{ic|all.use_tempaddr}} or {{ic|default.use_tempaddr}} parameters are not applied to nic's that already exist when the [[sysctl]] settings are executed. <br />
<br />
After a reboot, at the latest, Privacy Extensions should be enabled.<br />
<br />
=== dhcpcd ===<br />
<br />
[[dhcpcd]] includes in its default configuration file since version 6.4.0 the option {{ic|slaac private}}, which enables "Stable Private IPv6 Addresses instead of hardware based ones", implementing [https://tools.ietf.org/html/rfc7217 RFC 7217] ([http://roy.marples.name/projects/dhcpcd/info/8aa9dab00dc72c453aeccbde885ecce27a3d81ff commit]). Therefore, it is not necessary to change anything, except if it is desired to change of IPv6 address more often than each time the system is connected to a new network.<br />
<br />
=== NetworkManager ===<br />
<br />
NetworkManager does not honour the settings placed in {{ic|/etc/sysctl.d/40-ipv6.conf}}. This can be verified by running {{ic|$ ip -6 addr show ''interface''}} after rebooting: no {{ic|scope global '''temporary'''}} address appears besides the regular one.<br />
<br />
To enable IPv6 Privacy Extensions by default, add these lines to {{ic|/etc/NetworkManager/NetworkManager.conf}}<br />
{{hc|/etc/NetworkManager/NetworkManager.conf|2=<br />
...<br />
'''[connection]'''<br />
'''ipv6.ip6-privacy=2'''<br />
}}<br />
<br />
In order to enable IPv6 Privacy Extensions for individual NetworkManager-managed connections, edit the desired connection keyfile in {{ic|/etc/NetworkManager/system-connections/}} and append to its {{ic|[ipv6]}} section the key-value pair {{ic|1=ip6-privacy=2}}:<br />
{{hc|/etc/NetworkManager/system-connections/''example_connection''|2=<br />
...<br />
[ipv6]<br />
method=auto<br />
'''ip6-privacy=2'''<br />
}}<br />
<br />
{{Note|Although it may seem the {{ic|scope global temporary}} IPv6 address created by enabling Privacy Extensions never gets renewed (it never shifts to {{ic|deprecated}} status at the term of its {{ic|valid_lft}} lifetime), it is to be verified over a longer period of time that this address '''does''' indeed change.}}<br />
<br />
=== systemd-networkd ===<br />
<br />
Systemd-networkd also does not honour the settings placed in {{ic|/etc/sysctl.d/40-ipv6.conf}} and needs the option {{ic|IPv6PrivacyExtensions}} to be set.<br />
<br />
See [[systemd-networkd]] and [http://www.freedesktop.org/software/systemd/man/systemd.network.html systemd.network(5) man page] for details.<br />
<br />
== Static address ==<br />
<br />
Sometime using static address can improve security. For example, if your local router uses Neighbor Discovery or radvd ([http://www.apps.ietf.org/rfc/rfc2461.html RFC 2461]), your interface will automatically be assigned an address based its MAC address (using IPv6's Stateless Autoconfiguration). This may be less than ideal for security since it allows a system to be tracked even if the network portion of the IP address changes.<br />
<br />
To assign a static IP address using [[netctl]], look at the example profile in {{ic|/etc/netctl/examples/ethernet-static}}. The following lines are important:<br />
<br />
...<br />
# For IPv6 static address configuration<br />
IP6=static<br />
Address6=('1234:5678:9abc:def::1/64' '1234:3456::123/96')<br />
Routes6=('abcd::1234')<br />
Gateway6='1234:0:123::abcd'<br />
{{Note|1=If you are connected IPv6-only, than you need to determine ipv6 dns server. For example<br />
DNS=('6666:6666::1' '6666:6666::2')<br />
If your provider did not give you ipv6 dns and you are not running your own, you can choose from [[resolv.conf]] article. <br />
}}<br />
<br />
== IPv6 and PPPoE ==<br />
<br />
The standard tool for PPPoE, {{ic|pppd}}, provides support for IPv6 on PPPoE as long as your ISP and your modem support it. Just add the following to {{ic|/etc/ppp/pppoe.conf}}<br />
<br />
+ipv6<br />
<br />
If you are using [[netctl]] for PPPoE then just add the following to your netctl configuration instead<br />
<br />
PPPoEIP6=yes<br />
<br />
== Prefix delegation (DHCPv6-PD) ==<br />
{{Note|This section is targeted towards custom gateway configuration, not client machines. For standard market routers please consult the documentation of your router on how to enable prefix delegation.}}<br />
<br />
Prefix delegation is a common IPv6 deployment technique used by many ISPs. It is a method of assigning a network prefix to a user site (ie. local network). A router can be configured to assign different network prefixes to various subnetworks. The ISP handles out a network prefix using DHCPv6 (usually a {{ic|/56}} or {{ic|/64}}) and a dhcp client assigns the prefixes to the local network. For a simple two interface gateway it practically assigns an IPv6 prefix to the interface connected to to the local network from an address acquired through the interface connected to WAN (or a pseudo-interface such as ppp).<br />
<br />
=== With dibbler ===<br />
<br />
[http://klub.com.pl/dhcpv6/ Dibbler] is a portable DHCPv6 client a server which can be used for Prefix delegation. It is available in the [[AUR]] as {{AUR|dibbler}}.<br />
<br />
If you are using {{ic|dibbler}} edit {{ic|/etc/dibbler/client.conf}}<br />
<br />
log-mode short<br />
log-level 7<br />
# use the interface connected to your WAN<br />
iface "WAN" {<br />
ia<br />
pd<br />
}<br />
<br />
{{Tip|Read manpage '''{{ic|dibbler-client(8)}}''' for more information.}}<br />
<br />
=== With dhcpcd ===<br />
<br />
[[Dhcpcd]] apart from IPv4 dhcp support also provides a fairly complete implementation of the DHCPv6 client standard which includes DHCPv6-PD. If you are using {{ic|dhcpcd}} edit {{ic|/etc/dhcpcd.conf}}. You might already be using dhcpcd for IPv4 so just update your existing configuration.<br />
<br />
duid<br />
noipv6rs<br />
waitip 6<br />
# Uncomment this line if you are running dhcpcd for IPv6 only.<br />
#ipv6only<br />
<br />
# use the interface connected to WAN<br />
interface WAN<br />
ipv6rs<br />
iaid 1<br />
# use the interface connected to your LAN<br />
ia_pd 1 LAN<br />
#ia_pd 1/::/64 LAN/0/64<br />
<br />
This configuration will ask for a prefix from WAN interface ({{ic|WAN}}) and delegate it to the internal interface ({{ic|LAN}}).<br />
In the event that a {{ic|/64}} range is issued, you will need to use the 2nd {{ic|ia_pd instruction}} that is commented out instead.<br />
It will also disable router solicitations on all interfaces except for the WAN interface ({{ic|WAN}}).<br />
<br />
{{Tip|Also read: manpages '''{{ic|dhcpcd(8)}}''' and '''{{ic|dhcpcd.conf(5)}}'''.}}<br />
<br />
=== With WIDE-DHCPv6 ===<br />
<br />
[http://wide-dhcpv6.sourceforge.net/ WIDE-DHCPv6] is an open-source implementation of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) originally developed by the KAME project. It is available in the [[AUR]] as {{AUR|wide-dhcpv6}}.<br />
<br />
If you are using {{ic|wide-dhcpv6}} edit {{ic|/etc/wide-dhcpv6/dhcp6c.conf}}<br />
<br />
# use the interface connected to your WAN<br />
interface WAN {<br />
send ia-pd 0;<br />
};<br />
<br />
id-assoc pd 0 {<br />
# use the interface connected to your LAN<br />
prefix-interface LAN {<br />
sla-id 1;<br />
sla-len 8;<br />
};<br />
};<br />
<br />
{{Note|1={{ic|sla-len}} should be set so that {{ic|1=(WAN-prefix) + (sla-len) = 64}}. In this case it is set up for a {{ic|/56}} prefix 56+8=64. For a {{ic|/64}} prefix {{ic|sla-len}} should be {{ic|0}}.}}<br />
<br />
To enable/start wide-dhcpv6 client use the following command. Change {{ic|WAN}} with the interface that is connected to your WAN.<br />
# systemctl enable/start dhcp6c@WAN.service<br />
<br />
{{Tip|Read manpages '''{{ic|dhcp6c(8)}}''' and '''{{ic|dhcp6c.conf(5)}}''' for more information.}}<br />
<br />
== IPv6 on Comcast ==<br />
<br />
{{ic|dhcpcd -4}} or {{ic|dhcpcd -6}} worked using a Motorola SURFBoard 6141 and a Realtek RTL8168d/8111d. Either would work, but would not run dual stack: both protocols and addresses on one interface. (The {{ic|-6}} command would not work if {{ic|-4}} ran first, even after resetting the interface. And when it did, it gave the NIC a /128 address.) Try these commands:<br />
<br />
# dhclient -4 enp3s0<br />
# dhclient -P -v enp3s0<br />
<br />
The {{ic|-P}} argument grabs a lease of the IPv6 prefix only. {{ic|-v}} writes to {{ic|stdout}} what is also written to {{ic|/var/lib/dhclient/dhclient6.leases}}:<br />
<br />
Bound to *:546<br />
Listening on Socket/enp3s0<br />
Sending on Socket/enp3s0<br />
PRC: Confirming active lease (INIT-REBOOT).<br />
XMT: Forming Rebind, 0 ms elapsed.<br />
XMT: X-- IA_PD a1:b2:cd:e2<br />
XMT: | X-- Requested renew +3600<br />
XMT: | X-- Requested rebind +5400<br />
XMT: | | X-- '''IAPREFIX 1234:5:6700:890::/64'''<br />
<br />
{{ic|IAPREFIX}} is the necessary value. Substitute {{ic|::1}} before the CIDR slash to make the prefix a real address:<br />
<br />
# ip -6 addr add 1234:5:6700:890::1/64 dev enp3s0<br />
<br />
== Disable IPv6 ==<br />
<br />
{{Note|The Arch kernel has IPv6 support built in directly, therefore a module cannot be blacklisted.}}<br />
<br />
{{Expansion|Add reasons why users may want to disable IPv6, such as low-quality DNS servers or firewall rules}}<br />
<br />
=== Disable functionality ===<br />
{{Warning|Disabling the IPv6 stack can break certain programs which expect it to be enabled. {{bug|46297}}}}<br />
<br />
Adding {{ic|1=ipv6.disable=1}} to the kernel line disables the whole IPv6 stack, which is likely what you want if you are experiencing issues. See [[Kernel parameters]] for more information.<br />
<br />
Alternatively, adding {{ic|1=ipv6.disable_ipv6=1}} instead will keep the IPv6 stack functional but will not assign IPv6 addresses to any of your network devices.<br />
<br />
One can also avoid assigning IPv6 addresses to specific network interfaces by adding the following sysctl config to {{ic|/etc/sysctl.d/40-ipv6.conf}}:<br />
<br />
# Disable IPv6<br />
net.ipv6.conf.all.disable_ipv6 = 1<br />
net.ipv6.conf.''nic0''.disable_ipv6 = 1<br />
...<br />
net.ipv6.conf.''nicN''.disable_ipv6 = 1<br />
<br />
Note that you must list all of the targeted interfaces explicitly, as disabling {{ic|all.disable_ipv6}} does not apply to interfaces that are already "up" when sysctl settings are applied.<br />
<br />
Note 2, if disabling IPv6 by sysctl, you should comment out the IPv6 hosts in your {{ic|/etc/hosts}}:<br />
<br />
#<ip-address> <hostname.domain.org> <hostname><br />
127.0.0.1 localhost.localdomain localhost<br />
#::1 localhost.localdomain localhost<br />
<br />
otherwise there could be some connection errors because hosts are resolved to their IPv6 address which is not reachable.<br />
<br />
=== Other programs ===<br />
<br />
Disabling IPv6 functionality in the kernel does not prevent other programs from trying to use IPv6. In most cases, this is completely harmless, but if you find yourself having issues with that program, you should consult the program's manual pages for a way to disable that functionality.<br />
<br />
==== dhcpcd ====<br />
<br />
''dhcpcd'' will continue to harmlessly attempt to perform IPv6 router solicitation. To disable this, as stated in the {{ic|dhcpcd.conf (5)}} [[man page]], add the following to {{ic|/etc/dhcpcd.conf}}:<br />
<br />
noipv6rs<br />
noipv6<br />
<br />
==== NetworkManager ====<br />
<br />
{{Poor writing|Specific approach to disable via GUI}}<br />
<br />
To disable IPv6 in NetworkManager, right click the network status icon, and select ''Edit Connections > Wired > ''Network name'' > Edit > IPv6 Settings > Method > Ignore/Disabled''<br />
<br />
Then click "Save".<br />
<br />
==== ntpd ====<br />
<br />
Following advice in [[Systemd#Drop-in snippets]], change how systemd starts {{ic|ntpd.service}}:<br />
<br />
# systemctl edit ntpd.service<br />
<br />
This will create a drop-in snippet that will be run instead of the default {{ic|ntpd.service}}. The {{ic|-4}} flag prevents IPv6 from being used by the ntp daemon. Put the following into the drop-in snippet:<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/ntpd -4 -g -u ntp:ntp<br />
<br />
which first clears the previous {{ic|ExecStart}}, and then replaces it with one that includes the {{ic|-4}} flag.<br />
<br />
== See also ==<br />
<br />
* [https://www.kernel.org/doc/Documentation/networking/ipv6.txt IPv6] - kernel.org documentation<br />
* [http://www.ipsidixit.net/2012/08/09/ipv6-temporary-addresses-and-privacy-extensions/ IPv6 temporary addresses] - a summary about temporary addresses and privacy extensions<br />
* [http://tldp.org/HOWTO/Linux+IPv6-HOWTO/x513.html IPv6 prefixes] - a summary of prefix types<br />
* [http://tldp.org/HOWTO/Linux+IPv6-HOWTO/proc-sys-net-ipv6..html net.ipv6 options] - documentation of kernel parameters</div>Moviurohttps://wiki.archlinux.org/index.php?title=GNU_Screen&diff=403686GNU Screen2015-10-07T18:25:27Z<p>Moviuro: /* Autostart with systemd */ system/screen@.service -> user/screen.service</p>
<hr />
<div>[[Category:Terminal emulators]]<br />
[[ja:GNU Screen]]<br />
[[ru:GNU Screen]]<br />
[[zh-CN:GNU Screen]]<br />
{{Related articles start}}<br />
{{Related|tmux}}<br />
{{Related articles end}}<br />
[http://www.gnu.org/s/screen/ GNU Screen] is a wrapper that allows separation between the text program and the shell from which it was launched. This allows the user to, for example, start a text program in a terminal in X, kill X, and continue to interact with the program.<br />
<br />
== Installation ==<br />
<br />
GNU Screen can be [[pacman|installed]] using the {{pkg|screen}} package found in the [[official repositories]].<br />
<br />
== Usage == <br />
<br />
Commands are entered pressing {{ic|ctrl+a}} and then the key binding.<br />
<br />
=== Common Commands ===<br />
<br />
* {{ic|ctrl+a}} {{ic|?}} Displays commands and its defaults (VERY important)<br />
* {{ic|ctrl+a}} {{ic|:}} Enter to the command prompt of screen<br />
* {{ic|ctrl+a}} {{ic|"}} Window list<br />
* {{ic|ctrl+a}} {{ic|0}} opens window 0<br />
* {{ic|ctrl+a}} {{ic|A}} Rename the current window<br />
* {{ic|ctrl+a}} {{ic|a}} Sends {{ic|ctrl+a}} to the current window<br />
* {{ic|ctrl+a}} {{ic|c}} Create a new window (with shell)<br />
* {{ic|ctrl+a}} {{ic|S}} Split current region into two regions<br />
* {{ic|ctrl+a}} {{ic|tab}} Switch the input focus to the next region<br />
* {{ic|ctrl+a}} {{ic|ctrl+a}} Toggle between current and previous region<br />
* {{ic|ctrl+a}} {{ic|Esc}} Enter Copy Mode (use enter to select a range of text)<br />
* {{ic|ctrl+a}} {{ic|]}} Paste text<br />
* {{ic|ctrl+a}} {{ic|Q}} Close all regions but the current one<br />
* {{ic|ctrl+a}} {{ic|X}} Close the current region<br />
* {{ic|ctrl+a}} {{ic|d}} Detach from the current screen session, and leave it running. Use {{ic|screen -r}} to resume<br />
<br />
=== Command Prompt Commands ===<br />
<br />
* {{ic|ctrl+a}} {{ic|:quit}} Closes all windows and closes screen session<br />
* {{ic|ctrl+a}} {{ic|:source ~/.screenrc}} Reloads screenrc configuration file (can alternatively use /etc/screenrc)<br />
<br />
=== Named sessions ===<br />
<br />
To create a named session, run screen with the following command:<br />
<br />
$ screen -S ''session_name''<br />
<br />
To (re)name an existing a session, run the following command while screen is running:<br />
<br />
{{ic|ctrl+a}} {{ic|:sessionname ''session_name''}} <br />
<br />
To print a list of ''pid.tty.host'' strings identifying your screen sessions:<br />
<br />
$ screen -list<br />
<br />
To attach to a named screen session, run this command:<br />
<br />
$ screen -x ''session_name''<br />
<br />
or<br />
<br />
$ screen -r ''session_name''<br />
<br />
=== Autostart with systemd ===<br />
<br />
This service autostarts screen (e.g. {{ic|systemctl --user enable screen}}).<br />
<br />
{{hc|/etc/systemd/user/screen.service|<nowiki><br />
[Unit]<br />
Description=screen<br />
After=network.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/screen -DmS autoscreen<br />
ExecStop=/usr/bin/screen -S autoscreen -X quit<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Change the escape key ===<br />
<br />
The escape key can be changed with the {{ic|escape}} option in {{ic|~/.screenrc}}. For example:<br />
{{bc|escape ``}}<br />
sets the escape key to {{ic|`}} and<br />
{{bc|escape ^^^}}<br />
sets it to {{ic|ctrl+^}}.<br />
<br />
=== Start at window 1 ===<br />
<br />
By default, the first screen window is 0. If you'd rather never have a window 0 and start instead with 1, add the following lines on your configuration:<br />
<br />
{{hc|~/.screenrc|<br />
bind c screen 1<br />
bind ^c screen 1<br />
bind 0 select 10 <br />
screen 1<br />
}}<br />
<br />
=== Nested Screen Sessions ===<br />
<br />
It is possible to get stuck in a nested screen session. A common scenario: you start an ssh session from within a screen session. Within the ssh session, you start screen. By default, the outer screen session that was launched first responds to {{ic|ctrl+a}} commands. To send a command to the inner screen session, use {{ic|ctrl+a}} {{ic|a}}, followed by your command. For example:<br />
* {{ic|ctrl+a}} {{ic|a}} {{ic|d}} Detaches the inner screen session.<br />
* {{ic|ctrl+a}} {{ic|a}} {{ic|K}} Kills the inner screen session.<br />
<br />
=== Use 256 colors ===<br />
<br />
By default, screen uses an 8-color terminal emulator. To enable more colors, you need to be using a terminal that supports them and set the correct [http://aperiodic.net/screen/commands:term term] value. This will use [[wikipedia:Terminfo|terminfo]] to describe how the [[wikipedia:ANSI escape code|ANSI escape codes]] will be interpreted. An entry in the terminfo database structure must exist, {{Pkg|ncurses}} provides many common descriptions stored under {{ic|/usr/share/terminfo/}}.<br />
<br />
First try the generic value:<br />
<br />
{{hc|~/.screenrc|<br />
term screen-256color<br />
}}<br />
<br />
If that does not work, try setting it based on the used terminal. When using [[xterm]]-based terminal:<br />
<br />
{{hc|~/.screenrc|<br />
term xterm-256color<br />
}}<br />
<br />
When using [[rxvt-unicode]]:<br />
<br />
{{hc|~/.screenrc|<br />
term rxvt-unicode-256color<br />
}}<br />
<br />
{{Note|{{ic|/usr/share/terminfo/r/rxvt-unicode-256color}} is provided by {{Pkg|rxvt-unicode-terminfo}}, which is installed as a dependency of {{Pkg|rxvt-unicode}}. However, if you log into a server via [[SSH]] and run ''screen'' there, this terminfo file might not be available on the server. In this case it is recommended to copy {{ic|/usr/share/terminfo/r/rxvt-unicode-256color}} on the server, it can be saved in {{ic|~/.terminfo}}.}}<br />
<br />
As a last resort, try setting [http://aperiodic.net/screen/commands:termcapinfo termcapinfo] instead:<br />
<br />
{{hc|~/.screenrc|<nowiki><br />
attrcolor b ".I" # allow bold colors - necessary for some reason<br />
termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm' # tell screen how to set colors. AB = background, AF=foreground<br />
defbce on # use current bg color for erased chars<br />
</nowiki>}}<br />
<br />
=== Informative statusbar ===<br />
<br />
The default statusbar may be a little lacking. You may find this one more helpful:<br />
<br />
{{hc|~/.screenrc|<nowiki><br />
hardstatus off<br />
hardstatus alwayslastline<br />
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %m-%d %{W} %c %{g}]'<br />
</nowiki>}}<br />
<br />
Another possibility, taken from [http://www.fordfrog.com/2012/09/02/71/ frodfrog's blog] is:<br />
<br />
{{hc|~/.screenrc|<nowiki><br />
hardstatus alwayslastline '%{= G}[ %{G}%H %{g}][%= %{= w}%?%-Lw%?%{= R}%n*%f %t%?%{= R}(%u)%?%{= w}%+Lw%?%= %{= g}][ %{y}Load: %l %{g}][%{B}%Y-%m-%d %{W}%c:%s %{g}]'<br />
</nowiki>}}<br />
<br />
=== Turn welcome message off ===<br />
<br />
{{hc|~/.screenrc|<br />
startup_message off<br />
}}<br />
<br />
=== Turn your hardstatus line into a dynamic urxvt|xterm|aterm window title ===<br />
<br />
This one is pretty simple; just switch your current {{ic|hardstatus}} line into a {{ic|caption}} line with notification, and edit accordingly:<br />
{{hc|~/.screenrc|<nowiki><br />
backtick 1 5 5 true<br />
termcapinfo rxvt* 'hs:ts=\E]2;:fs=\007:ds=\E]2;\007'<br />
hardstatus string "screen (%n: %t)"<br />
caption string "%{= kw}%Y-%m-%d;%c %{= kw}%-Lw%{= kG}%{+b}[%n %t]%{-b}%{= kw}%+Lw%1`"<br />
caption always<br />
</nowiki>}}<br />
<br />
This will give you something like {{ic|screen (0 bash)}} in the title of your terminal emulator. The caption supplies the date, current time, and colorizes your screen window collection.<br />
<br />
===Use X scrolling mechanism===<br />
<br />
The scroll buffer of GNU Screen can be accessed with {{ic|ctrl+a}} {{ic|[}}. However, this is very inconvenient. To use the scroll bar of e.g. xterm or konsole, add the following line:<br />
{{hc|~/.screenrc|<br />
termcapinfo xterm* ti@:te@<br />
}}<br />
<br />
=== Attach an existing running program to screen ===<br />
<br />
If you started a program outside screen, but now you would like it to be inside, you can use '''reptyr''' to reparent the process from it's current tty to one inside screen.<br />
<br />
[[Pacman|Install]] the package {{Pkg|reptyr}} from the [[official repositories]]. <br />
<br />
Get the PID of the process (you can use {{ic|ps ax}} for that). Now just enter the PID as argument to reptyr inside a screen window.<br />
{{bc|$ reptyr ''<pid>''}}<br />
<br />
===Setting a different bash prompt while in screen===<br />
<br />
If you want a different bash prompt when in a screen session, add the following to your .bashrc:<br />
{{bc|<nowiki><br />
if [ -z $STY ]<br />
then<br />
PS1="YOUR REGULAR PROMPT"<br />
else <br />
PS1="YOUR SCREEN PROMPT"<br />
fi<br />
</nowiki>}}<br />
[http://serverfault.com/questions/257975/how-to-check-if-im-in-screen-session]<br />
<br />
===Turn off visual bell===<br />
<br />
With this setting, screen will not make an ugly screen flash instead of a bell sound.<br />
{{hc|~/.screenrc|<br />
vbell off<br />
}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Fix Midnight Commander hard hang when starting in screen ===<br />
<br />
In some cases (need deeper inspection) [https://bugzilla.redhat.com/show_bug.cgi?id=168076 old gpm bug] gets alive. So, then you try to run mc inside screen, you get a frozen screen window. Try to kill gpm daemon before starting mc and/or disable it in {{ic|/etc/[[rc.conf]]}}.<br />
<br />
=== Fix for residual editor text ===<br />
<br />
When you open a text editor like nano in screen and then close it, the text may stay visible in your terminal. To fix this, put the following:<br />
{{hc|~/.screenrc|<br />
altscreen on<br />
}}<br />
<br />
=== Fix for Name column in windowlist only show "bash" ===<br />
add following to ~/.screenrc<br />
{{hc|head=~/.screenrc|output=windowlist string "%4n %h%=%f"}}<br />
<br />
== See also ==<br />
<br />
* [http://www.macosxhints.com/article.php?story=20021114055617124 MacOSX Hints - Automatically using screen in your shell]<br />
* [http://wiki.gentoo.org/wiki/Screen Gentoo Wiki - Tutorial for screen]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=50647 Arch Forums - Regarding 256 color issue with urxvt]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=55618 Arch Forums - .screenrc configs with screenshots]<br />
* [[Ratpoison|Ratpoison - A window manager based on gnu screen]]<br />
* [[Xpra|Xpra - An utility to detach/reattach X programs, in a way similar as screen does for command line based programs]]</div>Moviurohttps://wiki.archlinux.org/index.php?title=Systemd-boot&diff=403458Systemd-boot2015-10-05T20:07:02Z<p>Moviuro: /* Encrypted Root Installations */ add note: you can use UUIDs too here on that line</p>
<hr />
<div>{{lowercase title}}<br />
[[Category:Boot loaders]]<br />
[[de:Gummiboot]]<br />
[[es:Gummiboot]]<br />
[[ja:Systemd-boot]]<br />
[[ru:Gummiboot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related articles end}}<br />
<br />
'''systemd-boot''' (previously called '''gummiboot'''), is a simple UEFI boot manager which executes configured EFI images. The default entry is selected by a configured pattern (glob) or an on-screen menu. It is included with systemd since {{Pkg|systemd}} 220-2.<br />
<br />
It is simple to configure, but can only start EFI executables, such as the Linux kernel [[EFISTUB]], UEFI Shell, GRUB, the Windows Boot Manager, and such.<br />
<br />
{{Warning|systemd-boot simply provides a boot menu for EFISTUB kernels. In case you have issues booting EFISTUB kernels like in {{Bug|33745}}, you should use a boot loader which does not use EFISTUB, like [[GRUB]], [[Syslinux]] or [[Boot loaders#ELILO|ELILO]].}}<br />
<br />
{{Note|In the entire article {{ic|$esp}} denotes the mountpoint of the [[UEFI#EFI System Partition|EFI System Partition]] aka ESP.}}<br />
<br />
== Installation ==<br />
<br />
=== EFI boot ===<br />
First, make sure you are booted in UEFI mode, [[Unified_Extensible_Firmware_Interface#Requirements_for_UEFI_variable_support|your EFI variables are accessible]], your EFI System Partition is properly mounted and your kernel and initramfs are copied onto that ESP as systemd-boot cannot load EFI binaries from other partitions. It is therefore strongly recommended to mount your ESP to {{ic|/boot}}. See [[#Updating]] for more information and work-around, in case you want to separate {{ic|/boot}} from the ESP. <br />
<br />
Finally, type the following command to copy the systemd-boot binary to your EFI System Partition and add systemd-boot itself as the default EFI application (default boot entry) loaded by the EFI Boot Manager. If you are not booted in UEFI mode and your EFI variables are not accessible, creating the boot entry will fail. You should however still be able to boot systemd-boot as it copies the binary to the default EFI binary location on your ESP ({{ic|$esp/EFI/boot/systemd-bootx64.efi}} on x64 systems) unless a non-systemd-boot EFI application is already present as the same filename.<br />
<br />
# bootctl --path=''$esp'' install<br />
<br />
=== Legacy boot ===<br />
{{Warning|This is not the recommended process}}<br />
You can also successfully install systemd-boot if booted with a legacy OS. However, this requires that you later on tell your firmware to launch systemd-boot's EFI file on boot:<br />
* you either have a working EFI shell somewhere;<br />
* or your firmware interface provides you with a way of properly setting the EFI file that will be loaded at boot time.<br />
{{Note|E.g. on Dell's Latitude series, the firmware interface provides everything you need to setup EFI boot, and the EFI Shell won't be able to write to the computer's ROM.}}<br />
If you can do so, the installation is easier: go into your EFI shell or your firmware configuration interface, and change your machine's default EFI file to {{ic|/$esp/EFI/boot/systemd-bootx64.efi}} ({{ic|systemd-bootia32.efi}} on i686 systems).<br />
<br />
=== Updating ===<br />
<br />
systemd-boot (bootctl(1), systemd-efi-boot-generator(8)) assumes that your EFI System Partition is mounted on {{ic|/boot}}. Unlike the previous separate ''gummiboot'' package, which updated automatically on a new package release with a {{ic|post_install}} script, updates of new systemd-boot versions are now handled manually by the user: <br />
<br />
# bootctl update <br />
<br />
If the ESP is not mounted on {{ic|/boot}}, the {{ic|1=--path=}} option can pass it. For example: <br />
<br />
# bootctl --path=/boot/$esp update<br />
<br />
== Configuration ==<br />
<br />
=== Basic configuration ===<br />
<br />
The basic configuration is kept in {{ic|$esp/loader/loader.conf}}, with just two possible configuration options:<br />
<br />
* {{ic|default}} – default entry to select (without the {{ic|.conf}} suffix); can be a wildcard like {{ic|arch-*}}<br />
<br />
* {{ic|timeout}} – menu timeout in seconds. If this is not set, the menu will only be shown when you hold the space key while booting.<br />
<br />
Example:<br />
<br />
{{hc|$esp/loader/loader.conf|<br />
default arch<br />
timeout 4<br />
}}<br />
<br />
Note that both options can be changed in the boot menu itself, which will store them as EFI variables.<br />
<br />
{{Note|If no timeout is configured, which is the default setting, and no key pressed during bootup, the default entry is executed right away.}}<br />
<br />
=== Adding boot entries ===<br />
{{Note|bootctl will automatically check for "'''Windows Boot Manager'''" ({{ic|\EFI\Microsoft\Boot\Bootmgfw.efi}}), "'''EFI Shell'''" ({{ic|\shellx64.efi}}) and "'''EFI Default Loader'''" ({{ic|\EFI\Boot\bootx64.efi}}). Where detected, entries will also automatically be generated for them as well. However, it does not auto-detect other EFI applications (unlike [[rEFInd]]), so for booting the kernel, manual configuration entries must be created.<br />
If you dual-boot Windows, it is strongly recommended to disable its default [[Windows_and_Arch_dual_boot#Fast_Start-Up|Fast Start-Up]] option.}}<br />
<br />
{{Tip|You can find the PARTUUID for your Root partition with the command {{ic|1=blkid -s PARTUUID -o value /dev/sdxY}}, where 'x' is the device letter and 'Y' is the partition number. This is required only for your Root partition, not $esp.}}<br />
<br />
bootctl searches for boot menu items in {{ic|$esp/loader/entries/*.conf}} – each file found must contain exactly one boot entry. The possible options are:<br />
<br />
* {{ic|title}} – operating system name. '''Required.'''<br />
<br />
* {{ic|version}} – kernel version, shown only when multiple entries with same title exist. Optional.<br />
<br />
* {{ic|machine-id}} – machine identifier from {{ic|/etc/machine-id}}, shown only when multiple entries with same title and version exist. Optional.<br />
<br />
* {{ic|efi}} – EFI program to start, relative to your ESP ({{ic|$esp}}); e.g. {{ic|/vmlinuz-linux}}. Either this or {{ic|linux}} (see below) is '''required.'''<br />
<br />
* {{ic|options}} – command line options to pass to the EFI program. Optional, but you will need at least {{ic|1=initrd=''efipath''}} and {{ic|1=root=''dev''}} if booting Linux.<br />
<br />
For Linux, you can specify {{ic|linux ''path-to-vmlinuz''}} and {{ic|initrd ''path-to-initramfs''}}; this will be automatically translated to {{ic|efi ''path''}} and {{ic|1=options initrd=''path''}} – this syntax is only supported for convenience and has no differences in function. <br />
<br />
==== Standard root installations ====<br />
<br />
Here is an example entry for a root partition without LVM or LUKS:<br />
<br />
{{hc|$esp/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw<br />
}}<br />
<br />
Please note in the example above that PARTUUID/PARTLABEL identifies a GPT partition, and differs from UUID/LABEL, which identifies a filesystem. Using the PARTUUID/PARTLABEL is advantageous because it is invariant (i.e. unchanging) if you reformat the partition with another filesystem, or if the /dev/sd* mapping changed for some reason. It is also useful if you do not have a filesystem on the partition (or use LUKS, which does not support LABELs).<br />
<br />
==== LVM root installations ====<br />
<br />
Here is an example for a root partition using [[LVM|Logical Volume Management]]:<br />
<br />
{{hc|$esp/loader/entries/arch-lvm.conf|2=<br />
title Arch Linux (LVM)<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=/dev/mapper/<VolumeGroup-LogicalVolume> rw<br />
}}<br />
<br />
Replace {{ic|<VolumeGroup-LogicalVolume>}} with the actual VG and LV names (e.g. {{ic|1=root=/dev/mapper/volgroup00-lvolroot}}). Alternatively, it is also possible to use a UUID instead:<br />
....<br />
options root=UUID=<UUID identifier> rw<br />
<br />
Note that {{ic|1=root='''UUID'''=}} is used instead of {{ic|1=root='''PARTUUID'''=}}, which is used for Root partitions without LVM or LUKS.<br />
<br />
==== Encrypted Root Installations ====<br />
<br />
Here is an example configuration file for an encrypted root partition ([[Dm-crypt|DM-Crypt / LUKS]]):<br />
<br />
{{hc|$esp/loader/entries/arch-encrypted.conf|2=<br />
title Arch Linux Encrypted<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options cryptdevice=UUID=<UUID>:<mapped-name> root=/dev/mapper/<mapped-name> quiet rw<br />
}}<br />
<br />
UUID is used in this example; PARTUUID should be able to replace the UUID, if so desired. You may also replace the /dev path with a regular UUID. See [[Dm-crypt/System configuration#Boot loader]].<br />
<br />
You can also add other EFI programs such as {{ic|\EFI\arch\grub.efi}}.<br />
<br />
==== btrfs subvolume root installations ====<br />
<br />
If booting a [[btrfs]] subvolume as root, amend the {{ic|options}} line with {{ic|rootflags<nowiki>=</nowiki>subvol<nowiki>=</nowiki><root subvolume>}}. In the example below, root has been mounted as a btrfs subvolume called 'ROOT' (e.g. {{ic|mount -o subvol<nowiki>=</nowiki>ROOT /dev/sdxY /mnt}}):<br />
<br />
{{hc|$esp/loader/entries/arch-btrfs-subvol.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw rootflags<nowiki>=</nowiki>subvol<nowiki>=</nowiki>ROOT<br />
}}<br />
<br />
A failure to do so will otherwise result in the following error message: {{ic|ERROR: Root device mounted successfully, but /sbin/init does not exist.}}<br />
<br />
==== EFI Shells or other EFI apps ====<br />
<br />
In case you installed EFI shells and other EFI application into the ESP, you can use the following snippets:<br />
<br />
{{hc|$esp/loader/entries/uefi-shell-v1-x86_64.conf|2=<br />
title UEFI Shell x86_64 v1<br />
efi /EFI/shellx64_v1.efi<br />
}}<br />
<br />
{{hc|$esp/loader/entries/uefi-shell-v2-x86_64.conf|2=<br />
title UEFI Shell x86_64 v2<br />
efi /EFI/shellx64_v2.efi<br />
}}<br />
<br />
{{Expansion|Add example on how to boot into EFI firmware setup.}}<br />
<br />
=== Add security ===<br />
<br />
You have to note that the kernel command line parameters can be edited from systemd-boot's boot menu (see [[#Keys inside the boot menu]]) by pressing {{ic|e}}. This is a major security flaw since if you redefine the {{ic|1=init=}} kernel argument with {{ic|1=init=/bin/bash}} for example, this will boot your machine directly as root without any password, bypassing easily the root password that has been defined! Since systemd-boot does not currently have a password feature and has no ability to prevent kernel parameters changes, you need to make sure to define a password at hardware level (UEFI/BIOS) which prevents the computer to boot if the right password has not been entered.<br />
<br />
Since security is made of several levels and physical access already breaks any security systems, maybe encrypting your disk with [[dm-crypt]] would come in handy especially if your machine is a laptop. But this is another concern not related to systemd-boot.<br />
<br />
=== Support hibernation ===<br />
<br />
See [[Suspend and hibernate]].<br />
<br />
== Keys inside the boot menu ==<br />
<br />
The following keys are used inside the menu:<br />
* {{ic|Up/Down}} - select entry<br />
* {{ic|Enter}} - boot the selected entry<br />
* {{ic|d}} - select the default entry to boot (stored in a non-volatile EFI variable)<br />
* {{ic|-/T}} - decrease the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|+/t}} - increase the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|e}} - edit the kernel command line<br />
* {{ic|v}} - show the gummiboot and UEFI version<br />
* {{ic|Q}} - quit<br />
* {{ic|P}} - print the current configuration<br />
* {{ic|h/?}} - help<br />
<br />
These hotkeys will, when pressed inside the menu or during bootup, directly boot<br />
a specific entry:<br />
<br />
* {{ic|l}} - Linux<br />
* {{ic|w}} - Windows<br />
* {{ic|a}} - OS X<br />
* {{ic|s}} - EFI Shell<br />
* {{ic|1-9}} - number of entry<br />
<br />
== Troubleshooting ==<br />
<br />
=== Manual entry using efibootmgr ===<br />
<br />
If {{ic|bootctl install}} command failed, you can create a EFI boot entry manually using {{Pkg|efibootmgr}}:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/systemd/systemd-bootx64.efi -L "Linux Boot Manager"<br />
<br />
where {{ic|/dev/sdXY}} is the [[UEFI#EFI System Partition|EFI System Partition]].<br />
<br />
=== Menu does not appear after Windows upgrade ===<br />
<br />
For example, if you upgraded from Windows 8 to Windows 8.1, and you no longer see a boot menu after the upgrade (i.e., Windows boots immediately):<br />
<br />
* Make sure Secure Boot (UEFI setting) and [[Windows_and_Arch_dual_boot#Fast_Start-Up|Fast Startup]] (Windows power option setting) are both disabled.<br />
* Make sure your UEFI prefers Linux Boot Manager over Windows Boot Manager (UEFI setting like Hard Drive Disk Priority).<br />
<br />
{{Note|Windows 8.x+, including Windows 10, will overwrite any UEFI choices you make and install itself as the priority boot choice after every boot. Changing the boot order in the UEFI firmware will only last until the next Windows 10 boot. Know what the ''Change Boot Option'' key is for your motherboard.}}<br />
<br />
To make Windows 8.X and above respect your boot order, you must enter a Windows group policy and have it execute a batch (''.bat'') file on startup. In Windows:<br />
<br />
# Open a command prompt with admin privlages. Type in {{ic|bcdedit /enum firmware}}<br />
# Find the Firmware Application that has "Linux" in the description, e.g. "Linux Boot Manager"<br />
# Copy the Identifier, including the brackets, e.g. {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}<br />
# Open ''gpedit'' and under ''Local Computer Policy > Computer Configuration > Windows Settings > Scripts(Startup/Shutdown)'', choose ''Startup''. That should open a window named ''Startup Properties''.<br />
# Under the ''Scripts'' tab, choose the ''Add'' button<br />
# Give your script a name, e.g. {{ic|bootorder.bat}}.<br />
# Under ''Script Parameters'', type {{ic|bcdedit /set {fwbootmgr} DEFAULT {''identifier_copied_in_step_3''<nowiki>}</nowiki>}} (e.g. {{ic|<nowiki>bcdedit /set {fwbootmgr} DEFAULT {31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}).<br />
<br />
If this does not work, create a batch file somewhere on your Windows system with the {{ic|bcdedit /set {fwbootmgr} DEFAULT {''identifier_copied_in_step_3''<nowiki>}</nowiki>}} line in it and go back to step 6 and ''Browse'' for that file.<br />
<br />
Alternatively, you can make the default Windows boot loader load systemd-boot instead. In an administrator command prompt in Windows, one can change this entry as follows:<br />
<br />
bcdedit /set {bootmgr} path \EFI\systemd\systemd-bootx64.efi<br />
<br />
== See also ==<br />
<br />
* http://www.freedesktop.org/wiki/Software/systemd/systemd-boot/</div>Moviurohttps://wiki.archlinux.org/index.php?title=Sync_laptop_desktop&diff=396458Sync laptop desktop2015-08-29T16:14:03Z<p>Moviuro: Syncthing is a viable and compatible solution</p>
<hr />
<div>[[Category:Internet applications]]<br />
[[fr:Synchroniser vos ordinateurs]]<br />
{{Expansion}}<br />
{{Poor writing|first person}}<br />
It is not always possible to copy one computer's drive to the other. For example, some files must differ on both machines, or respective updates do not match.<br />
<br />
==Unison==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison/ Unison]. <br />
[http://caml.inria.fr/about/successes-images/unison.jpg Screenshot].<br />
<br />
You need to have ssh on both machines, and (the same version of) unison installed on both <br />
machines (your laptop and desktop). Then with a few simple commands you <br />
can synchronise directories, and in a GUI you can select which things <br />
you wish to have synchronised and which not. You can also resolve <br />
conflicts.<br />
<br />
'''~/.unison/electra.prf''' (laptop)<br />
root = /home/hugo<br />
<nowiki>root = ssh://pyros//home/hugo</nowiki><br />
follow = Path school<br />
include common<br />
<br />
'''~/.unison/pyros.prf''' (desktop)<br />
root = /home/hugo<br />
<nowiki>root = ssh://electra//home/hugo</nowiki><br />
follow = Path school<br />
include common<br />
<br />
'''~/.unison/common'''<br />
ignore = Regex .*(cache|Cache|te?mp|history|thumbnails).*<br />
ignore = Name sylpheed.log*<br />
ignore = Name unison.log<br />
ignore = Name .ICEauthority<br />
ignore = Name .Xauthority<br />
ignore = Path {.songinfo,.radinfo}<br />
ignore = Path .adesklets<br />
ignore = Path .Azureus<br />
ignore = Path .forward<br />
ignore = Path adesklets<br />
ignore = Path .ethereal<br />
ignore = Path .sheep<br />
ignore = Path .xinitrc<br />
ignore = Path .config<br />
ignore = Path .xscreensaver<br />
ignore = Path .xawtv<br />
ignore = Path .radio<br />
ignore = Path .forward<br />
ignore = Path .dc++<br />
ignore = Path .quodlibet<br />
ignore = Path .tvtime<br />
ignore = Path .config/graveman<br />
ignore = Path .xmodmap<br />
ignore = Path .java<br />
ignore = Path .tvlist*<br />
ignore = Path .thumbnails<br />
ignore = Path .ssh<br />
ignore = Path .viminfo<br />
ignore = Path .vim/tmp<br />
ignore = Path Desktop<br />
ignore = Path .wine*<br />
ignore = Path motion<br />
ignore = Path src/ufobot/test_pipe<br />
ignore = Path tmp<br />
ignore = Path local<br />
ignore = Path books<br />
ignore = Path .mozilla/firefox/*/Cache*<br />
ignore = Path .liferea/cache<br />
ignore = Path .liferea/mozilla/liferea/Cache<br />
ignore = Path .sylpheed-*/*.bak<br />
ignore = Path .sylpheed-*/folderlist.xml*<br />
ignore = Path .liferea/new_subscription<br />
ignore = Path .mozilla/firefox/pluginreg.dat<br />
ignore = Path .mozilla/firefox/*/lock<br />
ignore = Path .mozilla/firefox/*/XUL.mfasl<br />
ignore = Path .mozilla/firefox/*/xpti.dat<br />
ignore = Path .mozilla/firefox/*/cookies.txt<br />
ignore = Path .xbindkeysrc<br />
ignore = Path .unison/ar*<br />
ignore = Path .gaim/icons<br />
ignore = Path .gaim/blist.xml<br />
ignore = Path .asoundrc<br />
ignore = Path .maillog<br />
ignore = Path .openoffice2/.lock<br />
<br />
As you can see, there are two different profiles, one for running from <br />
the laptop, and one for running the desktop. Files are posted <br />
here as example, they are nowhere essential for your configuration.<br />
<br />
Bash aliases were created for quick usage. One example is:<br />
<br />
alias unisync="unison-gtk2 electra -contactquietly -logfile /dev/null"<br />
<br />
This starts unisync using profile 'electra', for when running the<br />
laptop.<br />
<br />
A line in ~/Desktop/autostart automates the process when wanting to sync desktop with laptop:<br />
<br />
xterm -e 'ping -q -W 2 -c 2 pyros &&<br />
unison-gtk2 electra -contactquietly -logfile /dev/null &&<br />
gxmessage -buttons no:0,yes:1 Syncing done. Shutdown pyros? ||<br />
ssh pyros sudo halt' &<br />
<br />
=== Limitations ===<br />
<br />
You can also use this tool with NFS shares, but you may find that it is <br />
slower, because using the ssh solution it asks the other side to check <br />
for updates, and thus not requiring network traffic for that part of the syncing process.<br />
<br />
If you are using a ssh port different from the default (22), <br />
for example 1022, use this line in your prf file: <br />
sshargs = -p 1022<br />
<br />
If you are using symbolic links and want to synchronise your files on a <br />
vfat system (usb key for example), unison will not accept them and <br />
generate errors. You cannot just tell unison you do not want symbolic <br />
links, you have to name them all. To find them on your system, you can <br />
run <br />
find ~/folder -type l<br />
<br />
Unison is very sensitive and requires the '''exact same versions''' on [https://groups.yahoo.com/neo/groups/unison-users/conversations/topics/11439|both client and server]. Also, unison '''must''' be compiled against the same OCaml version on all peers too. Making it highly unfeasible for a heterogeneous network.<br />
<br />
== rsync ==<br />
<br />
See [[rsync]]<br />
<br />
== rdiff-backup ==<br />
<br />
The following tool was used with the following backup script:<br />
<br />
#!/bin/sh<br />
<br />
mount /bak<br />
#mount /boot<br />
mount /mnt/win<br />
<br />
rdiff-backup \<br />
--exclude-regexp 'cache$' \<br />
--exclude-regexp '(?i)/te?mp$' \<br />
--exclude /mnt \<br />
--exclude /vol \<br />
--exclude /bak \<br />
--exclude /usr/media \<br />
--exclude /usr/media/misc \<br />
--exclude /usr/lib \<br />
--exclude /tmp \<br />
--exclude /var/dl \<br />
--exclude /var/spool \<br />
--exclude /var/cache \<br />
--exclude /proc \<br />
--exclude /dev \<br />
--exclude /sys \<br />
/ /bak/sys<br />
<br />
echo "----------------------------------------"<br />
echo " * Listing increments of backup"<br />
echo "----------------------------------------"<br />
rdiff-backup --list-increments /bak/sys<br />
<br />
echo ""<br />
echo "----------------------------------------"<br />
echo " * Removing backups older than 5 Weeks"<br />
echo "----------------------------------------"<br />
rdiff-backup --force --remove-older-than 5W /bak/sys<br />
<br />
##Force is necessary because:<br />
#Fatal Error: Found 2 relevant increments, dated:<br />
#Sat Apr 10 12:39:24 2004<br />
#Sat Apr 17 04:15:01 2004<br />
#If you want to delete multiple increments in this way, use the --force.<br />
<br />
echo ""<br />
echo "----------------------------------------"<br />
echo " * Disk usage after backup"<br />
echo "----------------------------------------"<br />
df -h<br />
<br />
umount /bak<br />
#umount /boot<br />
umount /mnt/win<br />
<br />
==Syncthing==<br />
See [[syncthing]]</div>Moviurohttps://wiki.archlinux.org/index.php?title=Sync_laptop_desktop&diff=396457Sync laptop desktop2015-08-29T16:12:48Z<p>Moviuro: /* Limitations */ added a bug to limitations (please fix the extarnal link, it just won't do what I expect it to do)</p>
<hr />
<div>[[Category:Internet applications]]<br />
[[fr:Synchroniser vos ordinateurs]]<br />
{{Expansion}}<br />
{{Poor writing|first person}}<br />
It is not always possible to copy one computer's drive to the other. For example, some files must differ on both machines, or respective updates do not match.<br />
<br />
==Unison==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison/ Unison]. <br />
[http://caml.inria.fr/about/successes-images/unison.jpg Screenshot].<br />
<br />
You need to have ssh on both machines, and (the same version of) unison installed on both <br />
machines (your laptop and desktop). Then with a few simple commands you <br />
can synchronise directories, and in a GUI you can select which things <br />
you wish to have synchronised and which not. You can also resolve <br />
conflicts.<br />
<br />
'''~/.unison/electra.prf''' (laptop)<br />
root = /home/hugo<br />
<nowiki>root = ssh://pyros//home/hugo</nowiki><br />
follow = Path school<br />
include common<br />
<br />
'''~/.unison/pyros.prf''' (desktop)<br />
root = /home/hugo<br />
<nowiki>root = ssh://electra//home/hugo</nowiki><br />
follow = Path school<br />
include common<br />
<br />
'''~/.unison/common'''<br />
ignore = Regex .*(cache|Cache|te?mp|history|thumbnails).*<br />
ignore = Name sylpheed.log*<br />
ignore = Name unison.log<br />
ignore = Name .ICEauthority<br />
ignore = Name .Xauthority<br />
ignore = Path {.songinfo,.radinfo}<br />
ignore = Path .adesklets<br />
ignore = Path .Azureus<br />
ignore = Path .forward<br />
ignore = Path adesklets<br />
ignore = Path .ethereal<br />
ignore = Path .sheep<br />
ignore = Path .xinitrc<br />
ignore = Path .config<br />
ignore = Path .xscreensaver<br />
ignore = Path .xawtv<br />
ignore = Path .radio<br />
ignore = Path .forward<br />
ignore = Path .dc++<br />
ignore = Path .quodlibet<br />
ignore = Path .tvtime<br />
ignore = Path .config/graveman<br />
ignore = Path .xmodmap<br />
ignore = Path .java<br />
ignore = Path .tvlist*<br />
ignore = Path .thumbnails<br />
ignore = Path .ssh<br />
ignore = Path .viminfo<br />
ignore = Path .vim/tmp<br />
ignore = Path Desktop<br />
ignore = Path .wine*<br />
ignore = Path motion<br />
ignore = Path src/ufobot/test_pipe<br />
ignore = Path tmp<br />
ignore = Path local<br />
ignore = Path books<br />
ignore = Path .mozilla/firefox/*/Cache*<br />
ignore = Path .liferea/cache<br />
ignore = Path .liferea/mozilla/liferea/Cache<br />
ignore = Path .sylpheed-*/*.bak<br />
ignore = Path .sylpheed-*/folderlist.xml*<br />
ignore = Path .liferea/new_subscription<br />
ignore = Path .mozilla/firefox/pluginreg.dat<br />
ignore = Path .mozilla/firefox/*/lock<br />
ignore = Path .mozilla/firefox/*/XUL.mfasl<br />
ignore = Path .mozilla/firefox/*/xpti.dat<br />
ignore = Path .mozilla/firefox/*/cookies.txt<br />
ignore = Path .xbindkeysrc<br />
ignore = Path .unison/ar*<br />
ignore = Path .gaim/icons<br />
ignore = Path .gaim/blist.xml<br />
ignore = Path .asoundrc<br />
ignore = Path .maillog<br />
ignore = Path .openoffice2/.lock<br />
<br />
As you can see, there are two different profiles, one for running from <br />
the laptop, and one for running the desktop. Files are posted <br />
here as example, they are nowhere essential for your configuration.<br />
<br />
Bash aliases were created for quick usage. One example is:<br />
<br />
alias unisync="unison-gtk2 electra -contactquietly -logfile /dev/null"<br />
<br />
This starts unisync using profile 'electra', for when running the<br />
laptop.<br />
<br />
A line in ~/Desktop/autostart automates the process when wanting to sync desktop with laptop:<br />
<br />
xterm -e 'ping -q -W 2 -c 2 pyros &&<br />
unison-gtk2 electra -contactquietly -logfile /dev/null &&<br />
gxmessage -buttons no:0,yes:1 Syncing done. Shutdown pyros? ||<br />
ssh pyros sudo halt' &<br />
<br />
=== Limitations ===<br />
<br />
You can also use this tool with NFS shares, but you may find that it is <br />
slower, because using the ssh solution it asks the other side to check <br />
for updates, and thus not requiring network traffic for that part of the syncing process.<br />
<br />
If you are using a ssh port different from the default (22), <br />
for example 1022, use this line in your prf file: <br />
sshargs = -p 1022<br />
<br />
If you are using symbolic links and want to synchronise your files on a <br />
vfat system (usb key for example), unison will not accept them and <br />
generate errors. You cannot just tell unison you do not want symbolic <br />
links, you have to name them all. To find them on your system, you can <br />
run <br />
find ~/folder -type l<br />
<br />
Unison is very sensitive and requires the '''exact same versions''' on [https://groups.yahoo.com/neo/groups/unison-users/conversations/topics/11439|both client and server]. Also, unison '''must''' be compiled against the same OCaml version on all peers too. Making it highly unfeasible for a heterogeneous network.<br />
<br />
== rsync ==<br />
<br />
See [[rsync]]<br />
<br />
== rdiff-backup ==<br />
<br />
The following tool was used with the following backup script:<br />
<br />
#!/bin/sh<br />
<br />
mount /bak<br />
#mount /boot<br />
mount /mnt/win<br />
<br />
rdiff-backup \<br />
--exclude-regexp 'cache$' \<br />
--exclude-regexp '(?i)/te?mp$' \<br />
--exclude /mnt \<br />
--exclude /vol \<br />
--exclude /bak \<br />
--exclude /usr/media \<br />
--exclude /usr/media/misc \<br />
--exclude /usr/lib \<br />
--exclude /tmp \<br />
--exclude /var/dl \<br />
--exclude /var/spool \<br />
--exclude /var/cache \<br />
--exclude /proc \<br />
--exclude /dev \<br />
--exclude /sys \<br />
/ /bak/sys<br />
<br />
echo "----------------------------------------"<br />
echo " * Listing increments of backup"<br />
echo "----------------------------------------"<br />
rdiff-backup --list-increments /bak/sys<br />
<br />
echo ""<br />
echo "----------------------------------------"<br />
echo " * Removing backups older than 5 Weeks"<br />
echo "----------------------------------------"<br />
rdiff-backup --force --remove-older-than 5W /bak/sys<br />
<br />
##Force is necessary because:<br />
#Fatal Error: Found 2 relevant increments, dated:<br />
#Sat Apr 10 12:39:24 2004<br />
#Sat Apr 17 04:15:01 2004<br />
#If you want to delete multiple increments in this way, use the --force.<br />
<br />
echo ""<br />
echo "----------------------------------------"<br />
echo " * Disk usage after backup"<br />
echo "----------------------------------------"<br />
df -h<br />
<br />
umount /bak<br />
#umount /boot<br />
umount /mnt/win</div>Moviurohttps://wiki.archlinux.org/index.php?title=RTorrent&diff=388771RTorrent2015-07-28T21:20:23Z<p>Moviuro: /* systemd service file with tmux or screen */ %h instead of /home/%I</p>
<hr />
<div>{{DISPLAYTITLE:rTorrent}}<br />
[[Category:Internet applications]]<br />
[[es:RTorrent]]<br />
[[ja:RTorrent]]<br />
[[ru:RTorrent]]<br />
[[zh-CN:RTorrent]]<br />
[https://rakshasa.github.io/rtorrent/ rTorrent] is a quick and efficient BitTorrent client that uses, and is in development alongside, the libTorrent (not to be confused with {{Pkg|libtorrent-rasterbar}}) library. It is written in C++ and uses the [[Wikipedia:ncurses|ncurses]] programming library, which means it uses a text user interface. When combined with a terminal multiplexer (e.g. [[GNU Screen]] or [[Tmux]]) and [[Secure Shell]], it becomes a convenient remote [[Wikipedia:BitTorrent (protocol)#Operation|BitTorrent client]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|rtorrent}} package that is available in the [[official repositories]].<br />
<br />
Alternatively, install {{AUR|rtorrent-git}} or {{AUR|rtorrent-extended}} from the [[AUR]].<br />
<br />
== Configuration ==<br />
<br />
{{Note|See the rTorrent wiki article on this subject for more information: [http://web.archive.org/web/20140213003955/http://libtorrent.rakshasa.no/wiki/RTorrentCommonTasks Common Tasks in rTorrent for Dummies].}}<br />
<br />
Before running rTorrent, find the example configuration file {{ic|/usr/share/doc/rtorrent/rtorrent.rc}} and copy it to {{ic|~/.rtorrent.rc}}:<br />
<br />
$ cp /usr/share/doc/rtorrent/rtorrent.rc ~/.rtorrent.rc<br />
<br />
=== Performance ===<br />
<br />
{{Note|See the rTorrent wiki article on this subject for more information: [http://web.archive.org/web/20140213011439/http://libtorrent.rakshasa.no/wiki/RTorrentPerformanceTuning Performance Tuning]}}<br />
<br />
The values for the following options are dependent on the system's hardware and Internet connection speed. To find the optimal values read: [http://torrentfreak.com/optimize-your-BitTorrent-download-speed Optimize Your BitTorrent Download Speed]<br />
{{bc|<nowiki><br />
min_peers = 40<br />
max_peers = 52<br />
<br />
min_peers_seed = 10<br />
max_peers_seed = 52<br />
<br />
max_uploads = 8<br />
<br />
download_rate = 200<br />
upload_rate = 28<br />
</nowiki>}}<br />
<br />
The {{ic|check_hash}} option executes a hash check when a torrent download is complete or rTorrent is started. When starting, it checks for errors in your completed files. <br />
check_hash = yes<br />
<br />
=== Create and manage files ===<br />
<br />
The {{ic|directory}} option will determine where your torrent data will be saved (could be a relative path):<br />
directory = ~/downloaded<br />
<br />
The {{ic|session}} option allows rTorrent to save the progess of your torrents. It is recommended to create a directory in home directory (e.g. {{ic|mkdir ~/.rtorrent.session}}).<br />
session = ~/.rtorrent.session<br />
<br />
The {{ic|schedule}} option has rTorrent watch a particular directory for new torrent files. Saving a torrent file to this directory will automatically start the download. Remember to create the directory that will be watched (e.g. {{ic|mkdir ~/watch}}). Also, be careful when using this option as rTorrent will move the torrent file to your session folder and rename it to its hash value.<br />
schedule = watch_directory,5,5,load_start=/home/''user''/watch/*.torrent<br />
schedule = untied_directory,5,5,stop_untied=<br />
schedule = tied_directory,5,5,start_tied=<br />
<br />
The following {{ic|schedule}} option is intended to stop rTorrent from downloading data when disk space is low.<br />
schedule = low_diskspace,5,60,close_low_diskspace=100M<br />
<br />
=== Port configuration ===<br />
<br />
The {{ic|port_range}} option sets which port(s) to use for listening. It is recommended to use a port that is higher than 49152 (see: [[Wikipedia:List of TCP and UDP port numbers|List of port numbers]]). Although, rTorrent allows a range of ports, a single port is recommended.<br />
port_range = 49164-49164<br />
<br />
Additionally, make sure port forwarding is enabled for the proper port(s) (see: [http://portforward.com/english/routers/port_forwarding/routerindex.htm Port Forward guides]).<br />
<br />
=== Additional settings ===<br />
<br />
The {{ic|encryption}} option enables or disables encryption. It is very important to enable this option, not only for yourself, but also for your peers in the torrent swarm. Some users need to obscure their bandwidth usage from their ISP. And it does not hurt to enable it even if you do not need the added security.<br />
encryption = allow_incoming,try_outgoing,enable_retry<br />
It is also possible to force all connections to use encryption. However, be aware that this stricter rule will reduce your client's availability:<br />
encryption = require,require_RC4,allow_incoming,try_outgoing<br />
<br />
See also [[Wikipedia:BitTorrent Protocol Encryption]].<br />
<br />
This final {{ic|dht}} option enables [[Wikipedia:Distributed hash table|DHT]] support. DHT is common among public trackers and will allow the client to acquire more peers.<br />
{{bc|<nowiki><br />
dht = auto<br />
dht_port = 6881<br />
peer_exchange = yes<br />
</nowiki>}}<br />
<br />
== Key bindings ==<br />
<br />
rTorrent relies exclusively on keyboard shortcuts for user input. A quick reference is available in the table below. A complete guide is available on the rTorrent wiki (see: [https://github.com/rakshasa/rtorrent/wiki/User-Guide rTorrent User Guide]).<br />
<br />
{{Note|Striking {{ic|Ctrl-q}} twice in quick succession will make rTorrent shutdown without waiting to send a stop announce to the connected trackers.}}<br />
<br />
{| class="wikitable"<br />
|-<br />
!width="75" |Cmd<br />
!Action<br />
|-<br />
|Ctrl-q<br />
|Quit application<br />
|-<br />
|Ctrl-s<br />
|Start download. Runs hash first unless already done.<br />
|-<br />
|Ctrl-d<br />
|Stop an active download or remove a stopped download<br />
|-<br />
|Ctrl-k<br />
|Stop and close the files of an active download.<br />
|-<br />
|Ctrl-r<br />
|Initiate hash check of torrent. Without starting to download/upload.<br />
|-<br />
|Left<br />
|Returns to the previous screen<br />
|-<br />
|Right<br />
|Goes to the next screen<br />
|-<br />
|Backspace/Return<br />
|Adds the specified *.torrent<br />
|-<br />
|<nowiki>a|s|d</nowiki><br />
|<nowiki>Increase global upload throttle about 1|5|50 KB/s</nowiki><br />
|-<br />
|<nowiki>A|S|D</nowiki><br />
|<nowiki>Increase global download throttle about 1|5|50 KB/s</nowiki><br />
|-<br />
|<nowiki>z|x|c</nowiki><br />
|<nowiki>Decrease global upload throttle about 1|5|50 KB/s</nowiki><br />
|-<br />
|<nowiki>Z|X|C</nowiki><br />
|<nowiki>Decrease global download throttle about 1|5|50 KB/s</nowiki><br />
|}<br />
<br />
=== Redundant mapping ===<br />
<br />
{{ic|Ctrl-s}} is often used for terminal control to stop screen output while {{ic|Ctrl-q}} is used to start it. These mappings may interfere with rTorrent. Check to see if these terminal options are bound to a mapping:<br />
{{hc|$ stty -a|<nowiki>...<br />
swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;<br />
...<br />
</nowiki>}}<br />
<br />
To remove the mappings, change the terminal characteristics to undefine the aforementioned special characters (i.e. {{ic|stop}} and {{ic|start}}):<br />
# stty stop undef<br />
# stty start undef<br />
<br />
To remove these mappings automatically at startup you may add the two preceding commands to your {{ic|~/.bashrc}} file.<br />
<br />
== Additional tips ==<br />
<br />
=== systemd service file with tmux or screen ===<br />
<br />
*With tmux (Restart rtorrent if crashed)<br />
{{hc|/etc/systemd/user/rt.service|<nowiki><br />
[Unit]<br />
Description=rTorrent<br />
After=network.target<br />
<br />
[Service]<br />
Type=forking<br />
KillMode=none<br />
ExecStart=/usr/bin/tmux new-session -s rt -n rtorrent -d rtorrent<br />
ExecStop=/usr/bin/bash -c "/usr/bin/tmux send-keys -t rt:rtorrent C-q && while pidof rtorrent > /dev/null; do sleep 0.5; echo rtorrent still running...; done"<br />
WorkingDirectory=%h<br />
Restart=on-failure<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
*With tmux running as user rtorrent (Restart rtorrent if crashed)<br />
{{hc|/etc/systemd/system/rtorrent.service|<nowiki><br />
[Unit]<br />
Description=rTorrent Daemon<br />
After=network.target<br />
<br />
[Service]<br />
Type=forking<br />
KillMode=none<br />
User=rtorrent<br />
ExecStart=/usr/bin/tmux new-session -c /mnt/storage/rtorrent -s rtorrent -n rtorrent -d rtorrent<br />
ExecStop=/usr/bin/tmux send-keys -t rtorrent C-q && /usr/bin/tmux kill-session -t rtorrent<br />
WorkingDirectory=/home/rtorrent/<br />
Restart=on-failure<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
*With screen<br />
<br />
{{hc|/etc/systemd/user/rt.service|<nowiki><br />
[Unit]<br />
Description=rTorrent<br />
After=network.target<br />
<br />
[Service]<br />
Type=forking<br />
KillMode=none<br />
ExecStart=/usr/bin/screen -d -m -fa -S rtorrent /usr/bin/rtorrent<br />
ExecStop=/usr/bin/killall -w -s 2 /usr/bin/rtorrent<br />
WorkingDirectory=%h<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Start at boot time:<br />
$ systemctl --user enable rt<br />
Start manually:<br />
$ systemctl --user start rt<br />
Stop:<br />
$ systemctl --user stop rt<br />
Attach to rtorrent's session:<br />
tmux attach -t rt<br />
Detach:<br />
Ctrl-b d<br />
<br />
=== systemd service file with dtach ===<br />
<br />
{{Style|Creating multiple rtorrent sessions this way is far from perfect, why don't we just assume for simplicity that there is only one session? This is assumed in [[#systemd service file with tmux or screen]] anyway.}}<br />
<br />
When running dtach from systemd unit, the {{ic|TERM}} environment variable [[systemd/User#Environment_variables|has to be set explicitly]] for rtorrent to work.<br />
<br />
This service file has no restart because the author occasionally takes the drive in question offline, and rtorrent fails, shall we say, "suboptimally" when started in this scenario and loses many torrent specific settings such as the specific directories each torrent is stored in. In fact the symlinks that kick off rtorrent live on the relevant drive; if it is unmounted rtorrent cannot start. This use case of blocking rtorrent from starting is relevant to users who put the downloaded files on removable media such as NAS, USB or eSATA drives.<br />
<br />
{{hc|~/.config/systemd/user/rtorrent.service|<nowiki><br />
[Unit]<br />
Description=rTorrent<br />
#After=network.target<br />
<br />
[Service]<br />
# set TERM according to your terminal<br />
Environment="TERM=xterm"<br />
#Environment="TERM=linux" <br />
Type=forking<br />
KillMode=none<br />
ExecStart=-/usr/bin/dtach -n /home/sam/run/dtach_fifos/fifo -e "^T" /home/sam/bin/rtr_new -n -o import=/home/sam/.config/rtorrent/new_.rc <br />
# dtach -n <separate filename for each instance><br />
# <br />
# rtr_new -n to ignore the default .rtorrent.rc<br />
# rtr_new -o import to load the instance-specific rc<br />
ExecStop=-/usr/bin/killall -u sam -e -w -s INT /home/sam/bin/rtr_new<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Note some other issues exposed in this service file other than just dtach:<br />
<br />
{{ic|/home/sam/bin/rtr_new}} is a symlink to {{ic|/usr/bin/rtorrent}}<br />
<br />
This lets us run several instances and kill each one independently with a different version of the ExecStop, to wit:<br />
<br />
{{bc|1=ExecStop=-/usr/bin/killall -u sam -e -w -s INT /home/sam/bin/rtr_new<br />
ExecStop=-/usr/bin/killall -u sam -e -w -s INT /home/sam/bin/rtr_academic<br />
ExecStop=-/usr/bin/killall -u sam -e -w -s INT /home/sam/bin/rtr_other_stuff}}<br />
<br />
These are each in a different service file, each of which controls one instance.<br />
<br />
Without this step, when running multiple instances a killall solution would kill all the running rtorrent instances. <br />
<br />
If multiple rtorrent instances are not needed and the rtorrent rc file is in the default location the above service file may be simplified. The entire file is included but only the ExecStart and <br />
ExecStop lines change. <br />
<br />
{{hc|~/.config/systemd/user/rtorrent.service|<nowiki><br />
[Unit]<br />
Description=rTorrent<br />
#After=network.target<br />
<br />
[Service]<br />
# set TERM according to your terminal<br />
Environment="TERM=xterm"<br />
#Environment="TERM=linux" <br />
Type=forking<br />
KillMode=none<br />
ExecStart=-/usr/bin/dtach -n /home/sam/run/dtach_fifos/fifo -e "^T" /usr/bin/rtorrent <br />
# dtach -n <user specified FIFO name> -e <user specified character> /usr/bin/rtorrent <br />
ExecStop=/usr/bin/killall -w -s INT /usr/bin/rtorrent<br />
# -e (exact match) and -u (user name) were added above to stop specific processes<br />
# and may be omitted here because only one rtorrent will be running<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
The service can be controlled with [[systemctl --user]]. When it is started, you can attach to the session:<br />
<br />
$ dtach -a /home/sam/run/dtach_fifos/fifo -e "^T"<br />
<br />
=== Pre-allocation ===<br />
<br />
The rTorrent package in the community repository lacks pre-allocation. Compiling rTorrent with pre-allocation allows files to be allocated before downloading the torrent. The major benefit is that it limits and avoids fragmentation of the filesystem. However, this introduces a delay during the pre-allocation if the filesystem does not support the fallocate syscall natively.<br />
<br />
Therefore this switch is recommended for xfs, ext4 and btrfs filesystems, which have native fallocate syscall support. They will see no delay during preallocation and no fragmented filesystem. Pre-allocation on others filesystems will cause a delay but will not fragment the files.<br />
<br />
To make pre-allocation available, recompile libTorrent from the [[ABS]] tree with the following new switch:<br />
$ ./configure --prefix=/usr --disable-debug --with-posix-fallocate<br />
<br />
To enable it, add the following to your {{ic|~/rtorrent.rc}}:<br />
{{hc|~/rtorrent.rc|<nowiki><br />
# Preallocate files; reduces defragmentation on filesystems.<br />
system.file_allocate.set = yes<br />
</nowiki>}}<br />
<br />
=== Manage completed files ===<br />
<br />
{{Note|<br />
*Currently, this part requires either the git version of rtorrent/libtorrent or having applied the patch to 0.8.6 that adds 'equal'.<br />
* If you are having trouble with this tip, it is probably easier to follow [http://web.archive.org/web/20140213003955/http://libtorrent.rakshasa.no/wiki/RTorrentCommonTasks#Movecompletedtorrentstodifferentdirectorydependingonwatchdirectory this].<br />
}}<br />
<br />
It is possible to have rtorrent sort completed torrent data to specific folders based on which 'watch' folder you drop the *.torrent into while continuing to seed. Many examples show how to do this with torrents downloaded by rtorrent. The problem is when you try to drop in 100% done torrent data and then have rtorrent check the data and resume, it will not be sorted.<br />
<br />
As a solution, use the following example in your {{ic|~/.rtorrent.rc}}.<br />
Make sure to change the paths.<br />
<br />
{{bc|1=<br />
# location where new torrent data is placed, and where you should place your<br />
# 'complete' data before you place your *.torrent file into the watch folder<br />
directory = /home/user/torrents/incomplete<br />
<br />
# schedule a timer event named 'watch_directory_1':<br />
# 1) triggers 10 seconds after rtorrent starts<br />
# 2) triggers at 10 second intervals thereafter<br />
# 3) Upon trigger, attempt to load (and start) new *.torrent files found in /home/user/torrents/watch/<br />
# 4) set a variable named 'custom1' with the value "/home/user/torrents/complete"<br />
# NOTE: if you do not want it to automatically start the torrent, change 'load_start' to 'load'<br />
schedule = watch_directory_1,10,10,"load_start=/home/user/torrents/watch/*.torrent,d.set_custom1=/home/user/torrents/complete"<br />
<br />
# insert a method with the alias 'checkdirs1'<br />
# 1) returns true if the current path of the torrent data is not equal to the value of custom1<br />
# 2) otherwise, returns false<br />
system.method.insert=checkdirs1,simple,"not=\"$equal={d.get_custom1=,d.get_base_path=}\""<br />
<br />
# insert a method with the alias 'movecheck1'<br />
# 1) returns true if all 3 commands return true ('result of checkdirs1' && 'torrent is 100% done', 'custom1 variable is set')<br />
# 2) otherwise, returns false<br />
system.method.insert=movecheck1,simple,"and={checkdirs1=,d.get_complete=,d.get_custom1=}"<br />
<br />
# insert a method with the alias 'movedir1'<br />
# (a series of commands, separated by ';') <br />
# 1) "set path of torrent to equal the value of custom1";<br />
# 2) "mv -u <current data path> <custom1 path>";<br />
# 3) "clear custom1", "stop the torrent","resume the torrent"<br />
# 4) stop the torrent<br />
# 5) start the torrent (to get the torrent to update the 'base path')<br />
system.method.insert=movedir1,simple,"d.set_directory=$d.get_custom1=;execute=mv,-u,$d.get_base_path=,$d.get_custom1=;d.set_custom1=;d.stop=;d.start="<br />
<br />
# set a key with the name 'move_hashed1' that is triggered by the hash_done event.<br />
# 1) When hashing of a torrent completes, this custom key will be triggered.<br />
# 2) when triggered, execute the 'movecheck1' method and check the return value.<br />
# 3) if the 'movecheck' method returns 'true', execute the 'movedir1' method we inserted above.<br />
# NOTE-0: *Only* data that has had their hash checked manually with ^R [^R = Control r].<br />
# Or on a rtorrent restart[which initiates a hash check]. Will the data move; ~/torrents/incomplete => ~/torrents/complete for example.<br />
# NOTE-1: 'branch' is an 'if' conditional statement: if(movecheck1){movedir1}<br />
system.method.set_key=event.download.hash_done,move_hashed1,"branch={$movecheck1=,movedir1=}"<br />
}}<br />
<br />
You can add additional watch folders and rules should you like to sort your torrents into special folders.<br />
<br />
For example, if you would like the torrents to download in:<br />
/home/user/torrents/incomplete<br />
and then sort the torrent data based on which folder you dropped the *.torrent into:<br />
/home/user/torrents/watch => /home/user/torrents/complete<br />
/home/user/torrents/watch/iso => /home/user/torrents/complete/iso<br />
/home/user/torrents/watch/music => /home/user/torrents/complete/music<br />
<br />
You can have the following in your .rtorrent.rc:<br />
{{bc|1=<br />
directory = /home/user/torrents/incomplete<br />
schedule = watch_directory_1,10,10,"load_start=/home/user/torrents/watch/*.torrent,d.set_custom1=/home/user/torrents/complete"<br />
<br />
schedule = watch_directory_2,10,10,"load_start=/home/user/torrents/watch/iso/*.torrent,d.set_custom1=/home/user/torrents/complete/iso"<br />
<br />
schedule = watch_directory_3,10,10,"load_start=/home/user/torrents/watch/music/*.torrent,d.set_custom1=/home/user/torrents/complete/music"<br />
<br />
system.method.insert=checkdirs1,simple,"not=\"$equal={d.get_custom1=,d.get_base_path=}\""<br />
system.method.insert=movecheck1,simple,"and={checkdirs1=,d.get_complete=,d.get_custom1=}"<br />
system.method.insert=movedir1,simple,"d.set_directory=$d.get_custom1=;execute=mv,-u,$d.get_base_path=,$d.get_custom1=;d.set_custom1=;d.stop=;d.start="<br />
system.method.set_key=event.download.hash_done,move_hashed1,"branch={$movecheck1=,movedir1=}"<br />
}}<br />
<br />
Also see [http://code.google.com/p/pyroscope/ pyroscope] especially the rtcontrol examples. There is an AUR package.<br />
<br />
==== Notification with Google Mail ====<br />
<br />
Cell phone providers allow you to "email" your phone:<br />
{{bc|<nowiki><br />
Verizon: 10digitphonenumber@vtext.com<br />
AT&T: 10digitphonenumber@txt.att.net<br />
Former AT&T customers: 10digitphonenumber@mmode.com<br />
Sprint: 10digitphonenumber@messaging.sprintpcs.com<br />
T-Mobile: 10digitphonenumber@tmomail.net<br />
Nextel: 10digitphonenumber@messaging.nextel.com<br />
Cingular: 10digitphonenumber@cingularme.com<br />
Virgin Mobile: 10digitphonenumber@vmobl.com<br />
Alltel: 10digitphonenumber@alltelmessage.com OR<br />
10digitphonenumber@message.alltel.com<br />
CellularOne: 10digitphonenumber@mobile.celloneusa.com<br />
Omnipoint: 10digitphonenumber@omnipointpcs.com<br />
Qwest: 10digitphonenumber@qwestmp.com<br />
Telus: 10digitphonenumber@msg.telus.com<br />
Rogers Wireless: 10digitphonenumber@pcs.rogers.com<br />
Fido: 10digitphonenumber@fido.ca<br />
Bell Mobility: 10digitphonenumber@txt.bell.ca<br />
Koodo Mobile: 10digitphonenumber@msg.koodomobile.com<br />
MTS: 10digitphonenumber@text.mtsmobility.com<br />
President's Choice: 10digitphonenumber@txt.bell.ca<br />
Sasktel: 10digitphonenumber@sms.sasktel.com<br />
Solo: 10digitphonenumber@txt.bell.ca<br />
</nowiki>}}<br />
<br />
*Install mailx which is provided by the {{Pkg|s-nail}} package that is found in the [[official repositories]].<br />
<br />
*Clear the {{ic|/etc/mail.rc}} file and enter:<br />
<br />
{{bc|<nowiki><br />
set sendmail="/usr/bin/mailx"<br />
set smtp=smtp.gmail.com:587<br />
set smtp-use-starttls<br />
set ssl-verify=ignore<br />
set ssl-auth=login<br />
set smtp-auth-user=USERNAME@gmail.com<br />
set smtp-auth-password=PASSWORD<br />
</nowiki>}}<br />
<br />
Now to send the text, we must pipe a message to the mailx program.<br />
*Make a Bash script:<br />
{{hc|/path/to/mail.sh|<nowiki><br />
echo "$@: Done" | mailx 5551234567@vtext.com<br />
</nowiki>}}<br />
Where the $@ is a variable holding all the arguments passed to our script.<br />
<br />
*And finally, add the important {{ic|~/.rtorrent.rc}} line:<br />
system.method.set_key = event.download.finished,notify_me,"execute=/path/to/mail.sh,$d.get_name="<br />
<br />
Breaking it down:<br />
<br />
{{ic|notify_me}} is the command id, which may be used by other commands, it can be just about anything you like, so long as it is unique.<br />
<br />
{{ic|1=execute=}} is the rtorrent command, in this case to execute a shell command.<br />
<br />
{{ic|/path/to/mail.sh}} is the name of our script (or whatever command you want to execute) followed by a comma separated list of all the switches/arguments to be passed.<br />
<br />
{{ic|1=$d.get_name=}} 'd' is an alias to whatever download triggered the command, get_name is a function which returns the name of our download, and the '$' tells rTorrent to replace the command with its output before it calls execute.<br />
<br />
The end result? When that torrent, 'All Live Nudibranches', that we started before leaving for work finishes, we will be texted:<br />
All Live Nudibranches: Done<br />
<br />
=== Displaying active torrents ===<br />
<br />
The rtorrent does not list the active tab properly by default, add this line to your {{ic|.rtorrent.rc}} to show only active torrents<br />
schedule = filter_active,30,30,"view_filter = active,\"or={d.get_up_rate=,d.get_down_rate=}\""<br />
<br />
Then press {{ic|9}} in your rTorrent client to see the changes in action.<br />
<br />
=== Manually adding trackers to torrents ===<br />
<br />
# Select torrent to edit from rTorrent console view.<br />
# Hit {{ic|Ctrl+x}}.<br />
# If you had four trackers type following lines one at a time (always press {{ic|Ctrl+x}} first) to add four more for example:<br />
<br />
d.tracker.insert="5","udp://tracker.publicbt.com:80"<br />
d.tracker.insert="6","udp://tracker.openbittorrent.com:80"<br />
d.tracker.insert="7","udp://tracker.istole.it:80"<br />
d.tracker.insert="8","udp://tracker.ccc.de:80"<br />
<br />
== Troubleshooting ==<br />
<br />
=== CA certificates ===<br />
<br />
To use rTorrent with a tracker that uses HTTPS, do the following as root:<br />
<br />
{{bc|<br />
# cd /etc/ssl/certs<br />
<nowiki># wget --no-check-certificate https://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Global_eBusiness_CA-1.cer</nowiki><br />
# mv Equifax_Secure_Global_eBusiness_CA-1.cer Equifax_Secure_Global_eBusiness_CA-1.pem<br />
# c_rehash<br />
}}<br />
<br />
And from now on run rTorrent with:<br />
$ rtorrent -o http_capath=/etc/ssl/certs<br />
<br />
If you use GNU Screen, update the {{ic|.screenrc}} configuration file to reflect this change:<br />
$ screen -t rtorrent rtorrent -o http_capath=/etc/ssl/certs<br />
<br />
In rTorrent 0.8.9, set {{ic|<nowiki>network.http.ssl_verify_peer.set=0</nowiki>}} to [https://bbs.archlinux.org/viewtopic.php?pid=981832#p981832 fix the problem].<br />
<br />
For more information see: [https://bbs.archlinux.org/viewtopic.php?pid=331850 rTorrent Error & CA Certificate] and [https://bbs.archlinux.org/viewtopic.php?id=45800 rTorrent Certificates Problem]<br />
<br />
=== Locked directories ===<br />
<br />
rTorrent can sometimes lock up after a crash or incorrect shutdown, and will complain about a lock file.<br />
<br />
Per the error message, the file called "'''rtorrent.lock'''" can be found within the hidden folder {{ic|.rtorrentsession}} for your download directory and manually removed.<br />
<br />
=== Event failed: bad return code ===<br />
<br />
This is caused by there being spaces in your system.method.* lines. Remove the spaces and it will work.<br />
<br />
== Web interface ==<br />
<br />
There are numerous web interfaces and front ends for rTorrent including:<br />
* [[WTorrent]] is a web interface to rtorrent programmed in php using Smarty templates and XMLRPC for PHP library.<br />
* [http://code.google.com/p/ntorrent/ nTorrent] is a graphical user interface client to rtorrent (a cli torrent client) written in Java.<br />
* [http://projects.cyla.homeip.net/rtwi/ rTWi] is a simple rTorrent web interface written in PHP.<br />
* [[Rtgui]] is a web based front end for rTorrent written in PHP and uses XML-RPC to communicate with the rTorrent client.<br />
* [https://github.com/Novik/ruTorrent rutorrent] and [http://forums.rutorrent.org/ Forum] - A web-based front-end with an interface very similar to uTorrent which supports many plugins and advanced features (see also: [[ruTorrent]] and [https://bbs.archlinux.org/viewtopic.php?pid=897577#p897577 Guide on forum]).<br />
<br />
{{Note|rTorrent is currently built using [http://xmlrpc-c.sourceforge.net/ XML-RPC for C/C++], which is required for some web interfaces (e.g. ruTorrent).}}<br />
<br />
=== XMLRPC interface ===<br />
<br />
If you want to use rtorrent with some web interfaces (e.g. rutorrent) you need to add the following line to the configuration file:<br />
scgi_port = localhost:5000<br />
<br />
For more information see: [https://github.com/rakshasa/rtorrent/wiki/RPC-Setup-XMLRPC Using XMLRPC with rtorrent]<br />
<br />
=== Saving magnet links as torrent files in watch folder ===<br />
<br />
{{Note| Rtorrent natively supports downloading torrents through magnet links. At the main view (reached by starting Rtorrent and pressing 1), press enter. At "load.normal>" paste the magnet link and press enter again. This will start the download.}}<br />
<br />
If you wish to have magnet links automatically added to your watch folder, here is a script that will do the trick:<br />
<br />
<nowiki><br />
#!/bin/bash<br />
watch_folder=~/.rtorrent/watch<br />
cd $watch_folder<br />
[[ "$1" =~ xt=urn:btih:([^&/]+) ]] || exit;<br />
echo "d10:magnet-uri${#1}:${1}e" > "meta-${BASH_REMATCH[1]}.torrent"</nowiki><br />
<br />
(adapted from http://blog.gonzih.org/blog/2012/02/17/how-to-use-magnet-links-with-rtorrent/).<br />
<br />
Save it, for instance as rtorrent-magnet, give it execution permission, and place it somewhere under your $PATH. Then in Firefox:<br />
# Type {{ic|about:config}} into the Location Bar (address bar) and press {{ic|Enter}}.<br />
# Right-click: ''New > Boolean > Name: '''network.protocol-handler.expose.magnet''' > Value > false''.<br />
# Next time you click a magnet link you will be asked which application to open it with. Select the script we just created and you will be done.<br />
<br />
If you want xdg-open to handle this, which you need if you are using chrome instead of firefox, (though gnome and other DE might have their own programs overriding xdg-open) you need to create the desktop entry for the rtorrent-magnet script in {{ic|~/.local/share/applications/rtorrent-magnet.desktop}} with the following content:<br />
<br />
<nowiki><br />
[Desktop Entry]<br />
Type=Application<br />
Name=rtorrent-magnet<br />
Exec=rtorrent-magnet %U<br />
MimeType=x-scheme-handler/magnet;<br />
NoDisplay=true</nowiki><br />
<br />
Then all you need to do is to register the mimetype using<br />
$ xdg-mime default rtorrent-magnet.desktop x-scheme-handler/magnet<br />
<br />
== Magnet to Torrent ==<br />
You could also use the {{AUR|magnet2torrent-git}} package which downloads the metadata and creates a torrent file.<br />
<br />
How to use:<br />
$ magnet2torrent <magnet link> [torrent file]<br />
<br />
== rtorrent-pyro ==<br />
<br />
{{AUR|rtorrent-pyro}} from the [[AUR]] comes with an extended rtorrent console interface. It does not contain the pyroscope tools yet though. If you also need the pyroscope tools see [[#PyroScope]] .<br />
<br />
Make sure you add following command to ~/.rtorrent.rc, which makes the asterisk key * to a shortcut for toggling between extended and collapsed view within rtorrent's interface:<br />
{{bc|<nowiki>schedule = bind_collapse,0,0,"ui.bind_key=download_list,*,view.collapsed.toggle="</nowiki>}}<br />
<br />
Also set "pyro.extended" to 1 to activate rTorrent-PS features.<br />
{{bc|<nowiki>system.method.insert = pyro.extended, value|const, 1</nowiki>}}<br />
<br />
=== PyroScope ===<br />
<br />
We create a directory for the installation of pyroscope, then download and update the source code from subversion:<br />
{{bc|<nowiki>mkdir -p ~/.lib<br />
svn checkout http://pyroscope.googlecode.com/svn/trunk/ ~/.lib/pyroscope<br />
~/.lib/pyroscope/update-to-head.sh</nowiki>}}<br />
Adding pyroscope bin's PATH to .bashrc:<br />
{{bc|<nowiki>export PATH=$PATH:path_to_the_bin # Example path for pyroscope bin's: /home/user/.lib/pyroscope/bin/</nowiki>}}<br />
Creating the ~/.pyroscope/config.ini:<br />
{{bc|<nowiki>pyroadmin --create-config</nowiki>}}<br />
<br />
Add this to your ~/.rtorrent.rc. Do not forget to add the path of your pyroscope bin's dir (see below).<br />
{{bc|<nowiki>system.method.insert = pyro.bin_dir, string|const, write_here_path_to_your_pyroscope_bin_dir # Example path: /home/user/.lib/pyroscope/bin/<br />
system.method.insert = pyro.rc_dialect, string|const|simple, "execute_capture=bash,-c,\"test $1 = 0.8.6 && echo -n 0.8.6 || echo -n 0.8.9\",dialect,$system.client_version="<br />
system.method.insert = pyro.rtorrent_rc, string|const|private, "$cat=~/.pyroscope/rtorrent-,\"$pyro.rc_dialect=\",.rc.default"<br />
import = $pyro.rtorrent_rc=</nowiki>}}<br />
<br />
Optionally: TORQUE: Daemon watchdog schedule. Must be activated by touching the "~/.pyroscope/run/pyrotorque" file!<br />
You can also just use rtorrent watch dir or give pyro_watchdog a try, which comes with 'treewatch' ability, meaning it also watches for torrents recursively within the given watch path. Further documentation for pyro_watchdog is here: <br />
[http://code.google.com/p/pyroscope/wiki/QueueManager] <br />
To enable pyro_watchdog, add this in ~/.rtorrent.rc and further configurations are in ~/.pyroscope/torque.ini. <br />
{{bc|<nowiki>schedule = pyro_watchdog,30,300,"pyro.watchdog=~/.pyroscope,-v"</nowiki>}}<br />
<br />
Following steps are important. Before using pyroscope tools you have to set the missing "loaded" times to that of the .torrent file. Run this in your terminal:<br />
{{bc|<nowiki>rtcontrol '!*"*' loaded=0 -q -sname -o 'echo "$(name)s"\ntest -f "$(metafile)s" && rtxmlrpc -q d.set_custom $(hash)s tm_loaded \$(\<br />
ls -l --time-style "+%%s" "$(metafile)s" \<br />
| cut -f6 -d" ")\nrtxmlrpc -q d.save_session $(hash)s' | bash</nowiki>}}<br />
<br />
And now set the missing "completed" times to that of the data file or directory:<br />
{{bc|<nowiki>rtcontrol '!*"*' completed=0 done=100 path=\! is_ghost=no -q -sname -o 'echo "$(name)s"\ntest -e "$(realpath)s" && rtxmlrpc -q d.set_custom $(hash)s tm_completed \$(\<br />
ls -ld --time-style "+%%s" "$(realpath)s" \<br />
| cut -f6 -d" ")\nrtxmlrpc -q d.save_session $(hash)s' | bash</nowiki>}}<br />
<br />
Example usage:<br />
Will print out all torrents older than 2 hours:<br />
{{bc|<nowiki>rtcontrol -V completed=+2h -scompleted -ocompleted</nowiki>}}<br />
Deletes all torrents older than 48 hours:<br />
{{bc|<nowiki>rtcontrol -V completed=+48h -scompleted -ocompleted --cull --yes</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [http://libtorrent.rakshasa.no/rtorrent/rtorrent.1.html Manpage for rtorrent]<br />
* [[Screen Tips]]<br />
* [[Wikipedia:Comparison of BitTorrent clients|Comparison of BitTorrent clients]] on Wikipedia<br />
* [http://community.rutorrent.org/ rTorrent Community Wiki] - Public place for information on rTorrent and any project related to rTorrent, regarding setup, configuration, operations, and development.<br />
* [http://code.google.com/p/pyroscope/ PyroScope] - Collection of command line tools for rTorrent. It provides commands for creating and modifying torrent files, moving data on completion without having multiple watch folders, and mass-controlling download items via rTorrent's XML-RPC interface: searching, start/stop, deleting items with or without their data, etc. It also offers a documented [[Python]] API.<br />
* [[Rutorrent with lighttpd|ruTorrent with Lighttpd]]<br />
* [http://wiki.theaveragegeek.com/howto/installing_rtorrent_and_hellanzb_on_centos5_64-bit_vps How-to install rTorrent and Hellanzb on CentOS 5 64-bit VPS]<br />
* [http://code.google.com/p/pyroscope/wiki/DebianInstallFromSource Installation guide for rTorrent and Pryoscope on Debian] - Collection of tools for the BitTorrent protocol and especially the rTorrent client<br />
* [http://mktorrent.sourceforge.net/ mktorrent] - Command line application used to generate torrent files, which is available as {{Pkg|mktorrent}} in the [[official repositories]].<br />
* [https://github.com/kfei/docktorrent docktorrent] - Using Docker, rTorrent and ruTorrent to run a full-featured BitTorrent box.<br />
* [https://github.com/nelhage/reptyr reptyr] - another tool to take over a program's TTY (it is in the standard repos). The process may have started being attached to a terminal or to a socket in tmux, screen or dtach.<br />
* [http://caca.zoy.org/wiki/neercs neercs] - a more screen/tmux like tool than reptyr, but, like reptyr, neercs can also "steal" a process that may have started slaved to a terminal or to a socket in tmux, screen or dtach. {{AUR|neercs-git}}<br />
<br />
'''Forum threads'''<br />
* 2009-03-11 - Arch Linux - [https://bbs.archlinux.org/viewtopic.php?id=67304 HOWTO: rTorrent stats in Conky]</div>Moviurohttps://wiki.archlinux.org/index.php?title=RTorrent&diff=388770RTorrent2015-07-28T21:18:48Z<p>Moviuro: /* systemd service file with tmux or screen */ /etc/systemd/user exists for a reason</p>
<hr />
<div>{{DISPLAYTITLE:rTorrent}}<br />
[[Category:Internet applications]]<br />
[[es:RTorrent]]<br />
[[ja:RTorrent]]<br />
[[ru:RTorrent]]<br />
[[zh-CN:RTorrent]]<br />
[https://rakshasa.github.io/rtorrent/ rTorrent] is a quick and efficient BitTorrent client that uses, and is in development alongside, the libTorrent (not to be confused with {{Pkg|libtorrent-rasterbar}}) library. It is written in C++ and uses the [[Wikipedia:ncurses|ncurses]] programming library, which means it uses a text user interface. When combined with a terminal multiplexer (e.g. [[GNU Screen]] or [[Tmux]]) and [[Secure Shell]], it becomes a convenient remote [[Wikipedia:BitTorrent (protocol)#Operation|BitTorrent client]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|rtorrent}} package that is available in the [[official repositories]].<br />
<br />
Alternatively, install {{AUR|rtorrent-git}} or {{AUR|rtorrent-extended}} from the [[AUR]].<br />
<br />
== Configuration ==<br />
<br />
{{Note|See the rTorrent wiki article on this subject for more information: [http://web.archive.org/web/20140213003955/http://libtorrent.rakshasa.no/wiki/RTorrentCommonTasks Common Tasks in rTorrent for Dummies].}}<br />
<br />
Before running rTorrent, find the example configuration file {{ic|/usr/share/doc/rtorrent/rtorrent.rc}} and copy it to {{ic|~/.rtorrent.rc}}:<br />
<br />
$ cp /usr/share/doc/rtorrent/rtorrent.rc ~/.rtorrent.rc<br />
<br />
=== Performance ===<br />
<br />
{{Note|See the rTorrent wiki article on this subject for more information: [http://web.archive.org/web/20140213011439/http://libtorrent.rakshasa.no/wiki/RTorrentPerformanceTuning Performance Tuning]}}<br />
<br />
The values for the following options are dependent on the system's hardware and Internet connection speed. To find the optimal values read: [http://torrentfreak.com/optimize-your-BitTorrent-download-speed Optimize Your BitTorrent Download Speed]<br />
{{bc|<nowiki><br />
min_peers = 40<br />
max_peers = 52<br />
<br />
min_peers_seed = 10<br />
max_peers_seed = 52<br />
<br />
max_uploads = 8<br />
<br />
download_rate = 200<br />
upload_rate = 28<br />
</nowiki>}}<br />
<br />
The {{ic|check_hash}} option executes a hash check when a torrent download is complete or rTorrent is started. When starting, it checks for errors in your completed files. <br />
check_hash = yes<br />
<br />
=== Create and manage files ===<br />
<br />
The {{ic|directory}} option will determine where your torrent data will be saved (could be a relative path):<br />
directory = ~/downloaded<br />
<br />
The {{ic|session}} option allows rTorrent to save the progess of your torrents. It is recommended to create a directory in home directory (e.g. {{ic|mkdir ~/.rtorrent.session}}).<br />
session = ~/.rtorrent.session<br />
<br />
The {{ic|schedule}} option has rTorrent watch a particular directory for new torrent files. Saving a torrent file to this directory will automatically start the download. Remember to create the directory that will be watched (e.g. {{ic|mkdir ~/watch}}). Also, be careful when using this option as rTorrent will move the torrent file to your session folder and rename it to its hash value.<br />
schedule = watch_directory,5,5,load_start=/home/''user''/watch/*.torrent<br />
schedule = untied_directory,5,5,stop_untied=<br />
schedule = tied_directory,5,5,start_tied=<br />
<br />
The following {{ic|schedule}} option is intended to stop rTorrent from downloading data when disk space is low.<br />
schedule = low_diskspace,5,60,close_low_diskspace=100M<br />
<br />
=== Port configuration ===<br />
<br />
The {{ic|port_range}} option sets which port(s) to use for listening. It is recommended to use a port that is higher than 49152 (see: [[Wikipedia:List of TCP and UDP port numbers|List of port numbers]]). Although, rTorrent allows a range of ports, a single port is recommended.<br />
port_range = 49164-49164<br />
<br />
Additionally, make sure port forwarding is enabled for the proper port(s) (see: [http://portforward.com/english/routers/port_forwarding/routerindex.htm Port Forward guides]).<br />
<br />
=== Additional settings ===<br />
<br />
The {{ic|encryption}} option enables or disables encryption. It is very important to enable this option, not only for yourself, but also for your peers in the torrent swarm. Some users need to obscure their bandwidth usage from their ISP. And it does not hurt to enable it even if you do not need the added security.<br />
encryption = allow_incoming,try_outgoing,enable_retry<br />
It is also possible to force all connections to use encryption. However, be aware that this stricter rule will reduce your client's availability:<br />
encryption = require,require_RC4,allow_incoming,try_outgoing<br />
<br />
See also [[Wikipedia:BitTorrent Protocol Encryption]].<br />
<br />
This final {{ic|dht}} option enables [[Wikipedia:Distributed hash table|DHT]] support. DHT is common among public trackers and will allow the client to acquire more peers.<br />
{{bc|<nowiki><br />
dht = auto<br />
dht_port = 6881<br />
peer_exchange = yes<br />
</nowiki>}}<br />
<br />
== Key bindings ==<br />
<br />
rTorrent relies exclusively on keyboard shortcuts for user input. A quick reference is available in the table below. A complete guide is available on the rTorrent wiki (see: [https://github.com/rakshasa/rtorrent/wiki/User-Guide rTorrent User Guide]).<br />
<br />
{{Note|Striking {{ic|Ctrl-q}} twice in quick succession will make rTorrent shutdown without waiting to send a stop announce to the connected trackers.}}<br />
<br />
{| class="wikitable"<br />
|-<br />
!width="75" |Cmd<br />
!Action<br />
|-<br />
|Ctrl-q<br />
|Quit application<br />
|-<br />
|Ctrl-s<br />
|Start download. Runs hash first unless already done.<br />
|-<br />
|Ctrl-d<br />
|Stop an active download or remove a stopped download<br />
|-<br />
|Ctrl-k<br />
|Stop and close the files of an active download.<br />
|-<br />
|Ctrl-r<br />
|Initiate hash check of torrent. Without starting to download/upload.<br />
|-<br />
|Left<br />
|Returns to the previous screen<br />
|-<br />
|Right<br />
|Goes to the next screen<br />
|-<br />
|Backspace/Return<br />
|Adds the specified *.torrent<br />
|-<br />
|<nowiki>a|s|d</nowiki><br />
|<nowiki>Increase global upload throttle about 1|5|50 KB/s</nowiki><br />
|-<br />
|<nowiki>A|S|D</nowiki><br />
|<nowiki>Increase global download throttle about 1|5|50 KB/s</nowiki><br />
|-<br />
|<nowiki>z|x|c</nowiki><br />
|<nowiki>Decrease global upload throttle about 1|5|50 KB/s</nowiki><br />
|-<br />
|<nowiki>Z|X|C</nowiki><br />
|<nowiki>Decrease global download throttle about 1|5|50 KB/s</nowiki><br />
|}<br />
<br />
=== Redundant mapping ===<br />
<br />
{{ic|Ctrl-s}} is often used for terminal control to stop screen output while {{ic|Ctrl-q}} is used to start it. These mappings may interfere with rTorrent. Check to see if these terminal options are bound to a mapping:<br />
{{hc|$ stty -a|<nowiki>...<br />
swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;<br />
...<br />
</nowiki>}}<br />
<br />
To remove the mappings, change the terminal characteristics to undefine the aforementioned special characters (i.e. {{ic|stop}} and {{ic|start}}):<br />
# stty stop undef<br />
# stty start undef<br />
<br />
To remove these mappings automatically at startup you may add the two preceding commands to your {{ic|~/.bashrc}} file.<br />
<br />
== Additional tips ==<br />
<br />
=== systemd service file with tmux or screen ===<br />
<br />
*With tmux (Restart rtorrent if crashed)<br />
{{hc|/etc/systemd/user/rt.service|<nowiki><br />
[Unit]<br />
Description=rTorrent<br />
After=network.target<br />
<br />
[Service]<br />
Type=forking<br />
KillMode=none<br />
ExecStart=/usr/bin/tmux new-session -s rt -n rtorrent -d rtorrent<br />
ExecStop=/usr/bin/bash -c "/usr/bin/tmux send-keys -t rt:rtorrent C-q && while pidof rtorrent > /dev/null; do sleep 0.5; echo rtorrent still running...; done"<br />
WorkingDirectory=/home/%I/<br />
Restart=on-failure<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
*With tmux running as user rtorrent (Restart rtorrent if crashed)<br />
{{hc|/etc/systemd/system/rtorrent.service|<nowiki><br />
[Unit]<br />
Description=rTorrent Daemon<br />
After=network.target<br />
<br />
[Service]<br />
Type=forking<br />
KillMode=none<br />
User=rtorrent<br />
ExecStart=/usr/bin/tmux new-session -c /mnt/storage/rtorrent -s rtorrent -n rtorrent -d rtorrent<br />
ExecStop=/usr/bin/tmux send-keys -t rtorrent C-q && /usr/bin/tmux kill-session -t rtorrent<br />
WorkingDirectory=/home/rtorrent/<br />
Restart=on-failure<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
*With screen<br />
<br />
{{hc|/etc/systemd/user/rt.service|<nowiki><br />
[Unit]<br />
Description=rTorrent<br />
After=network.target<br />
<br />
[Service]<br />
Type=forking<br />
KillMode=none<br />
ExecStart=/usr/bin/screen -d -m -fa -S rtorrent /usr/bin/rtorrent<br />
ExecStop=/usr/bin/killall -w -s 2 /usr/bin/rtorrent<br />
WorkingDirectory=/home/%I/<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Start at boot time:<br />
$ systemctl --user enable rt<br />
Start manually:<br />
$ systemctl --user start rt<br />
Stop:<br />
$ systemctl --user stop rt<br />
Attach to rtorrent's session:<br />
tmux attach -t rt<br />
Detach:<br />
Ctrl-b d<br />
<br />
=== systemd service file with dtach ===<br />
<br />
{{Style|Creating multiple rtorrent sessions this way is far from perfect, why don't we just assume for simplicity that there is only one session? This is assumed in [[#systemd service file with tmux or screen]] anyway.}}<br />
<br />
When running dtach from systemd unit, the {{ic|TERM}} environment variable [[systemd/User#Environment_variables|has to be set explicitly]] for rtorrent to work.<br />
<br />
This service file has no restart because the author occasionally takes the drive in question offline, and rtorrent fails, shall we say, "suboptimally" when started in this scenario and loses many torrent specific settings such as the specific directories each torrent is stored in. In fact the symlinks that kick off rtorrent live on the relevant drive; if it is unmounted rtorrent cannot start. This use case of blocking rtorrent from starting is relevant to users who put the downloaded files on removable media such as NAS, USB or eSATA drives.<br />
<br />
{{hc|~/.config/systemd/user/rtorrent.service|<nowiki><br />
[Unit]<br />
Description=rTorrent<br />
#After=network.target<br />
<br />
[Service]<br />
# set TERM according to your terminal<br />
Environment="TERM=xterm"<br />
#Environment="TERM=linux" <br />
Type=forking<br />
KillMode=none<br />
ExecStart=-/usr/bin/dtach -n /home/sam/run/dtach_fifos/fifo -e "^T" /home/sam/bin/rtr_new -n -o import=/home/sam/.config/rtorrent/new_.rc <br />
# dtach -n <separate filename for each instance><br />
# <br />
# rtr_new -n to ignore the default .rtorrent.rc<br />
# rtr_new -o import to load the instance-specific rc<br />
ExecStop=-/usr/bin/killall -u sam -e -w -s INT /home/sam/bin/rtr_new<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Note some other issues exposed in this service file other than just dtach:<br />
<br />
{{ic|/home/sam/bin/rtr_new}} is a symlink to {{ic|/usr/bin/rtorrent}}<br />
<br />
This lets us run several instances and kill each one independently with a different version of the ExecStop, to wit:<br />
<br />
{{bc|1=ExecStop=-/usr/bin/killall -u sam -e -w -s INT /home/sam/bin/rtr_new<br />
ExecStop=-/usr/bin/killall -u sam -e -w -s INT /home/sam/bin/rtr_academic<br />
ExecStop=-/usr/bin/killall -u sam -e -w -s INT /home/sam/bin/rtr_other_stuff}}<br />
<br />
These are each in a different service file, each of which controls one instance.<br />
<br />
Without this step, when running multiple instances a killall solution would kill all the running rtorrent instances. <br />
<br />
If multiple rtorrent instances are not needed and the rtorrent rc file is in the default location the above service file may be simplified. The entire file is included but only the ExecStart and <br />
ExecStop lines change. <br />
<br />
{{hc|~/.config/systemd/user/rtorrent.service|<nowiki><br />
[Unit]<br />
Description=rTorrent<br />
#After=network.target<br />
<br />
[Service]<br />
# set TERM according to your terminal<br />
Environment="TERM=xterm"<br />
#Environment="TERM=linux" <br />
Type=forking<br />
KillMode=none<br />
ExecStart=-/usr/bin/dtach -n /home/sam/run/dtach_fifos/fifo -e "^T" /usr/bin/rtorrent <br />
# dtach -n <user specified FIFO name> -e <user specified character> /usr/bin/rtorrent <br />
ExecStop=/usr/bin/killall -w -s INT /usr/bin/rtorrent<br />
# -e (exact match) and -u (user name) were added above to stop specific processes<br />
# and may be omitted here because only one rtorrent will be running<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
The service can be controlled with [[systemctl --user]]. When it is started, you can attach to the session:<br />
<br />
$ dtach -a /home/sam/run/dtach_fifos/fifo -e "^T"<br />
<br />
=== Pre-allocation ===<br />
<br />
The rTorrent package in the community repository lacks pre-allocation. Compiling rTorrent with pre-allocation allows files to be allocated before downloading the torrent. The major benefit is that it limits and avoids fragmentation of the filesystem. However, this introduces a delay during the pre-allocation if the filesystem does not support the fallocate syscall natively.<br />
<br />
Therefore this switch is recommended for xfs, ext4 and btrfs filesystems, which have native fallocate syscall support. They will see no delay during preallocation and no fragmented filesystem. Pre-allocation on others filesystems will cause a delay but will not fragment the files.<br />
<br />
To make pre-allocation available, recompile libTorrent from the [[ABS]] tree with the following new switch:<br />
$ ./configure --prefix=/usr --disable-debug --with-posix-fallocate<br />
<br />
To enable it, add the following to your {{ic|~/rtorrent.rc}}:<br />
{{hc|~/rtorrent.rc|<nowiki><br />
# Preallocate files; reduces defragmentation on filesystems.<br />
system.file_allocate.set = yes<br />
</nowiki>}}<br />
<br />
=== Manage completed files ===<br />
<br />
{{Note|<br />
*Currently, this part requires either the git version of rtorrent/libtorrent or having applied the patch to 0.8.6 that adds 'equal'.<br />
* If you are having trouble with this tip, it is probably easier to follow [http://web.archive.org/web/20140213003955/http://libtorrent.rakshasa.no/wiki/RTorrentCommonTasks#Movecompletedtorrentstodifferentdirectorydependingonwatchdirectory this].<br />
}}<br />
<br />
It is possible to have rtorrent sort completed torrent data to specific folders based on which 'watch' folder you drop the *.torrent into while continuing to seed. Many examples show how to do this with torrents downloaded by rtorrent. The problem is when you try to drop in 100% done torrent data and then have rtorrent check the data and resume, it will not be sorted.<br />
<br />
As a solution, use the following example in your {{ic|~/.rtorrent.rc}}.<br />
Make sure to change the paths.<br />
<br />
{{bc|1=<br />
# location where new torrent data is placed, and where you should place your<br />
# 'complete' data before you place your *.torrent file into the watch folder<br />
directory = /home/user/torrents/incomplete<br />
<br />
# schedule a timer event named 'watch_directory_1':<br />
# 1) triggers 10 seconds after rtorrent starts<br />
# 2) triggers at 10 second intervals thereafter<br />
# 3) Upon trigger, attempt to load (and start) new *.torrent files found in /home/user/torrents/watch/<br />
# 4) set a variable named 'custom1' with the value "/home/user/torrents/complete"<br />
# NOTE: if you do not want it to automatically start the torrent, change 'load_start' to 'load'<br />
schedule = watch_directory_1,10,10,"load_start=/home/user/torrents/watch/*.torrent,d.set_custom1=/home/user/torrents/complete"<br />
<br />
# insert a method with the alias 'checkdirs1'<br />
# 1) returns true if the current path of the torrent data is not equal to the value of custom1<br />
# 2) otherwise, returns false<br />
system.method.insert=checkdirs1,simple,"not=\"$equal={d.get_custom1=,d.get_base_path=}\""<br />
<br />
# insert a method with the alias 'movecheck1'<br />
# 1) returns true if all 3 commands return true ('result of checkdirs1' && 'torrent is 100% done', 'custom1 variable is set')<br />
# 2) otherwise, returns false<br />
system.method.insert=movecheck1,simple,"and={checkdirs1=,d.get_complete=,d.get_custom1=}"<br />
<br />
# insert a method with the alias 'movedir1'<br />
# (a series of commands, separated by ';') <br />
# 1) "set path of torrent to equal the value of custom1";<br />
# 2) "mv -u <current data path> <custom1 path>";<br />
# 3) "clear custom1", "stop the torrent","resume the torrent"<br />
# 4) stop the torrent<br />
# 5) start the torrent (to get the torrent to update the 'base path')<br />
system.method.insert=movedir1,simple,"d.set_directory=$d.get_custom1=;execute=mv,-u,$d.get_base_path=,$d.get_custom1=;d.set_custom1=;d.stop=;d.start="<br />
<br />
# set a key with the name 'move_hashed1' that is triggered by the hash_done event.<br />
# 1) When hashing of a torrent completes, this custom key will be triggered.<br />
# 2) when triggered, execute the 'movecheck1' method and check the return value.<br />
# 3) if the 'movecheck' method returns 'true', execute the 'movedir1' method we inserted above.<br />
# NOTE-0: *Only* data that has had their hash checked manually with ^R [^R = Control r].<br />
# Or on a rtorrent restart[which initiates a hash check]. Will the data move; ~/torrents/incomplete => ~/torrents/complete for example.<br />
# NOTE-1: 'branch' is an 'if' conditional statement: if(movecheck1){movedir1}<br />
system.method.set_key=event.download.hash_done,move_hashed1,"branch={$movecheck1=,movedir1=}"<br />
}}<br />
<br />
You can add additional watch folders and rules should you like to sort your torrents into special folders.<br />
<br />
For example, if you would like the torrents to download in:<br />
/home/user/torrents/incomplete<br />
and then sort the torrent data based on which folder you dropped the *.torrent into:<br />
/home/user/torrents/watch => /home/user/torrents/complete<br />
/home/user/torrents/watch/iso => /home/user/torrents/complete/iso<br />
/home/user/torrents/watch/music => /home/user/torrents/complete/music<br />
<br />
You can have the following in your .rtorrent.rc:<br />
{{bc|1=<br />
directory = /home/user/torrents/incomplete<br />
schedule = watch_directory_1,10,10,"load_start=/home/user/torrents/watch/*.torrent,d.set_custom1=/home/user/torrents/complete"<br />
<br />
schedule = watch_directory_2,10,10,"load_start=/home/user/torrents/watch/iso/*.torrent,d.set_custom1=/home/user/torrents/complete/iso"<br />
<br />
schedule = watch_directory_3,10,10,"load_start=/home/user/torrents/watch/music/*.torrent,d.set_custom1=/home/user/torrents/complete/music"<br />
<br />
system.method.insert=checkdirs1,simple,"not=\"$equal={d.get_custom1=,d.get_base_path=}\""<br />
system.method.insert=movecheck1,simple,"and={checkdirs1=,d.get_complete=,d.get_custom1=}"<br />
system.method.insert=movedir1,simple,"d.set_directory=$d.get_custom1=;execute=mv,-u,$d.get_base_path=,$d.get_custom1=;d.set_custom1=;d.stop=;d.start="<br />
system.method.set_key=event.download.hash_done,move_hashed1,"branch={$movecheck1=,movedir1=}"<br />
}}<br />
<br />
Also see [http://code.google.com/p/pyroscope/ pyroscope] especially the rtcontrol examples. There is an AUR package.<br />
<br />
==== Notification with Google Mail ====<br />
<br />
Cell phone providers allow you to "email" your phone:<br />
{{bc|<nowiki><br />
Verizon: 10digitphonenumber@vtext.com<br />
AT&T: 10digitphonenumber@txt.att.net<br />
Former AT&T customers: 10digitphonenumber@mmode.com<br />
Sprint: 10digitphonenumber@messaging.sprintpcs.com<br />
T-Mobile: 10digitphonenumber@tmomail.net<br />
Nextel: 10digitphonenumber@messaging.nextel.com<br />
Cingular: 10digitphonenumber@cingularme.com<br />
Virgin Mobile: 10digitphonenumber@vmobl.com<br />
Alltel: 10digitphonenumber@alltelmessage.com OR<br />
10digitphonenumber@message.alltel.com<br />
CellularOne: 10digitphonenumber@mobile.celloneusa.com<br />
Omnipoint: 10digitphonenumber@omnipointpcs.com<br />
Qwest: 10digitphonenumber@qwestmp.com<br />
Telus: 10digitphonenumber@msg.telus.com<br />
Rogers Wireless: 10digitphonenumber@pcs.rogers.com<br />
Fido: 10digitphonenumber@fido.ca<br />
Bell Mobility: 10digitphonenumber@txt.bell.ca<br />
Koodo Mobile: 10digitphonenumber@msg.koodomobile.com<br />
MTS: 10digitphonenumber@text.mtsmobility.com<br />
President's Choice: 10digitphonenumber@txt.bell.ca<br />
Sasktel: 10digitphonenumber@sms.sasktel.com<br />
Solo: 10digitphonenumber@txt.bell.ca<br />
</nowiki>}}<br />
<br />
*Install mailx which is provided by the {{Pkg|s-nail}} package that is found in the [[official repositories]].<br />
<br />
*Clear the {{ic|/etc/mail.rc}} file and enter:<br />
<br />
{{bc|<nowiki><br />
set sendmail="/usr/bin/mailx"<br />
set smtp=smtp.gmail.com:587<br />
set smtp-use-starttls<br />
set ssl-verify=ignore<br />
set ssl-auth=login<br />
set smtp-auth-user=USERNAME@gmail.com<br />
set smtp-auth-password=PASSWORD<br />
</nowiki>}}<br />
<br />
Now to send the text, we must pipe a message to the mailx program.<br />
*Make a Bash script:<br />
{{hc|/path/to/mail.sh|<nowiki><br />
echo "$@: Done" | mailx 5551234567@vtext.com<br />
</nowiki>}}<br />
Where the $@ is a variable holding all the arguments passed to our script.<br />
<br />
*And finally, add the important {{ic|~/.rtorrent.rc}} line:<br />
system.method.set_key = event.download.finished,notify_me,"execute=/path/to/mail.sh,$d.get_name="<br />
<br />
Breaking it down:<br />
<br />
{{ic|notify_me}} is the command id, which may be used by other commands, it can be just about anything you like, so long as it is unique.<br />
<br />
{{ic|1=execute=}} is the rtorrent command, in this case to execute a shell command.<br />
<br />
{{ic|/path/to/mail.sh}} is the name of our script (or whatever command you want to execute) followed by a comma separated list of all the switches/arguments to be passed.<br />
<br />
{{ic|1=$d.get_name=}} 'd' is an alias to whatever download triggered the command, get_name is a function which returns the name of our download, and the '$' tells rTorrent to replace the command with its output before it calls execute.<br />
<br />
The end result? When that torrent, 'All Live Nudibranches', that we started before leaving for work finishes, we will be texted:<br />
All Live Nudibranches: Done<br />
<br />
=== Displaying active torrents ===<br />
<br />
The rtorrent does not list the active tab properly by default, add this line to your {{ic|.rtorrent.rc}} to show only active torrents<br />
schedule = filter_active,30,30,"view_filter = active,\"or={d.get_up_rate=,d.get_down_rate=}\""<br />
<br />
Then press {{ic|9}} in your rTorrent client to see the changes in action.<br />
<br />
=== Manually adding trackers to torrents ===<br />
<br />
# Select torrent to edit from rTorrent console view.<br />
# Hit {{ic|Ctrl+x}}.<br />
# If you had four trackers type following lines one at a time (always press {{ic|Ctrl+x}} first) to add four more for example:<br />
<br />
d.tracker.insert="5","udp://tracker.publicbt.com:80"<br />
d.tracker.insert="6","udp://tracker.openbittorrent.com:80"<br />
d.tracker.insert="7","udp://tracker.istole.it:80"<br />
d.tracker.insert="8","udp://tracker.ccc.de:80"<br />
<br />
== Troubleshooting ==<br />
<br />
=== CA certificates ===<br />
<br />
To use rTorrent with a tracker that uses HTTPS, do the following as root:<br />
<br />
{{bc|<br />
# cd /etc/ssl/certs<br />
<nowiki># wget --no-check-certificate https://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Global_eBusiness_CA-1.cer</nowiki><br />
# mv Equifax_Secure_Global_eBusiness_CA-1.cer Equifax_Secure_Global_eBusiness_CA-1.pem<br />
# c_rehash<br />
}}<br />
<br />
And from now on run rTorrent with:<br />
$ rtorrent -o http_capath=/etc/ssl/certs<br />
<br />
If you use GNU Screen, update the {{ic|.screenrc}} configuration file to reflect this change:<br />
$ screen -t rtorrent rtorrent -o http_capath=/etc/ssl/certs<br />
<br />
In rTorrent 0.8.9, set {{ic|<nowiki>network.http.ssl_verify_peer.set=0</nowiki>}} to [https://bbs.archlinux.org/viewtopic.php?pid=981832#p981832 fix the problem].<br />
<br />
For more information see: [https://bbs.archlinux.org/viewtopic.php?pid=331850 rTorrent Error & CA Certificate] and [https://bbs.archlinux.org/viewtopic.php?id=45800 rTorrent Certificates Problem]<br />
<br />
=== Locked directories ===<br />
<br />
rTorrent can sometimes lock up after a crash or incorrect shutdown, and will complain about a lock file.<br />
<br />
Per the error message, the file called "'''rtorrent.lock'''" can be found within the hidden folder {{ic|.rtorrentsession}} for your download directory and manually removed.<br />
<br />
=== Event failed: bad return code ===<br />
<br />
This is caused by there being spaces in your system.method.* lines. Remove the spaces and it will work.<br />
<br />
== Web interface ==<br />
<br />
There are numerous web interfaces and front ends for rTorrent including:<br />
* [[WTorrent]] is a web interface to rtorrent programmed in php using Smarty templates and XMLRPC for PHP library.<br />
* [http://code.google.com/p/ntorrent/ nTorrent] is a graphical user interface client to rtorrent (a cli torrent client) written in Java.<br />
* [http://projects.cyla.homeip.net/rtwi/ rTWi] is a simple rTorrent web interface written in PHP.<br />
* [[Rtgui]] is a web based front end for rTorrent written in PHP and uses XML-RPC to communicate with the rTorrent client.<br />
* [https://github.com/Novik/ruTorrent rutorrent] and [http://forums.rutorrent.org/ Forum] - A web-based front-end with an interface very similar to uTorrent which supports many plugins and advanced features (see also: [[ruTorrent]] and [https://bbs.archlinux.org/viewtopic.php?pid=897577#p897577 Guide on forum]).<br />
<br />
{{Note|rTorrent is currently built using [http://xmlrpc-c.sourceforge.net/ XML-RPC for C/C++], which is required for some web interfaces (e.g. ruTorrent).}}<br />
<br />
=== XMLRPC interface ===<br />
<br />
If you want to use rtorrent with some web interfaces (e.g. rutorrent) you need to add the following line to the configuration file:<br />
scgi_port = localhost:5000<br />
<br />
For more information see: [https://github.com/rakshasa/rtorrent/wiki/RPC-Setup-XMLRPC Using XMLRPC with rtorrent]<br />
<br />
=== Saving magnet links as torrent files in watch folder ===<br />
<br />
{{Note| Rtorrent natively supports downloading torrents through magnet links. At the main view (reached by starting Rtorrent and pressing 1), press enter. At "load.normal>" paste the magnet link and press enter again. This will start the download.}}<br />
<br />
If you wish to have magnet links automatically added to your watch folder, here is a script that will do the trick:<br />
<br />
<nowiki><br />
#!/bin/bash<br />
watch_folder=~/.rtorrent/watch<br />
cd $watch_folder<br />
[[ "$1" =~ xt=urn:btih:([^&/]+) ]] || exit;<br />
echo "d10:magnet-uri${#1}:${1}e" > "meta-${BASH_REMATCH[1]}.torrent"</nowiki><br />
<br />
(adapted from http://blog.gonzih.org/blog/2012/02/17/how-to-use-magnet-links-with-rtorrent/).<br />
<br />
Save it, for instance as rtorrent-magnet, give it execution permission, and place it somewhere under your $PATH. Then in Firefox:<br />
# Type {{ic|about:config}} into the Location Bar (address bar) and press {{ic|Enter}}.<br />
# Right-click: ''New > Boolean > Name: '''network.protocol-handler.expose.magnet''' > Value > false''.<br />
# Next time you click a magnet link you will be asked which application to open it with. Select the script we just created and you will be done.<br />
<br />
If you want xdg-open to handle this, which you need if you are using chrome instead of firefox, (though gnome and other DE might have their own programs overriding xdg-open) you need to create the desktop entry for the rtorrent-magnet script in {{ic|~/.local/share/applications/rtorrent-magnet.desktop}} with the following content:<br />
<br />
<nowiki><br />
[Desktop Entry]<br />
Type=Application<br />
Name=rtorrent-magnet<br />
Exec=rtorrent-magnet %U<br />
MimeType=x-scheme-handler/magnet;<br />
NoDisplay=true</nowiki><br />
<br />
Then all you need to do is to register the mimetype using<br />
$ xdg-mime default rtorrent-magnet.desktop x-scheme-handler/magnet<br />
<br />
== Magnet to Torrent ==<br />
You could also use the {{AUR|magnet2torrent-git}} package which downloads the metadata and creates a torrent file.<br />
<br />
How to use:<br />
$ magnet2torrent <magnet link> [torrent file]<br />
<br />
== rtorrent-pyro ==<br />
<br />
{{AUR|rtorrent-pyro}} from the [[AUR]] comes with an extended rtorrent console interface. It does not contain the pyroscope tools yet though. If you also need the pyroscope tools see [[#PyroScope]] .<br />
<br />
Make sure you add following command to ~/.rtorrent.rc, which makes the asterisk key * to a shortcut for toggling between extended and collapsed view within rtorrent's interface:<br />
{{bc|<nowiki>schedule = bind_collapse,0,0,"ui.bind_key=download_list,*,view.collapsed.toggle="</nowiki>}}<br />
<br />
Also set "pyro.extended" to 1 to activate rTorrent-PS features.<br />
{{bc|<nowiki>system.method.insert = pyro.extended, value|const, 1</nowiki>}}<br />
<br />
=== PyroScope ===<br />
<br />
We create a directory for the installation of pyroscope, then download and update the source code from subversion:<br />
{{bc|<nowiki>mkdir -p ~/.lib<br />
svn checkout http://pyroscope.googlecode.com/svn/trunk/ ~/.lib/pyroscope<br />
~/.lib/pyroscope/update-to-head.sh</nowiki>}}<br />
Adding pyroscope bin's PATH to .bashrc:<br />
{{bc|<nowiki>export PATH=$PATH:path_to_the_bin # Example path for pyroscope bin's: /home/user/.lib/pyroscope/bin/</nowiki>}}<br />
Creating the ~/.pyroscope/config.ini:<br />
{{bc|<nowiki>pyroadmin --create-config</nowiki>}}<br />
<br />
Add this to your ~/.rtorrent.rc. Do not forget to add the path of your pyroscope bin's dir (see below).<br />
{{bc|<nowiki>system.method.insert = pyro.bin_dir, string|const, write_here_path_to_your_pyroscope_bin_dir # Example path: /home/user/.lib/pyroscope/bin/<br />
system.method.insert = pyro.rc_dialect, string|const|simple, "execute_capture=bash,-c,\"test $1 = 0.8.6 && echo -n 0.8.6 || echo -n 0.8.9\",dialect,$system.client_version="<br />
system.method.insert = pyro.rtorrent_rc, string|const|private, "$cat=~/.pyroscope/rtorrent-,\"$pyro.rc_dialect=\",.rc.default"<br />
import = $pyro.rtorrent_rc=</nowiki>}}<br />
<br />
Optionally: TORQUE: Daemon watchdog schedule. Must be activated by touching the "~/.pyroscope/run/pyrotorque" file!<br />
You can also just use rtorrent watch dir or give pyro_watchdog a try, which comes with 'treewatch' ability, meaning it also watches for torrents recursively within the given watch path. Further documentation for pyro_watchdog is here: <br />
[http://code.google.com/p/pyroscope/wiki/QueueManager] <br />
To enable pyro_watchdog, add this in ~/.rtorrent.rc and further configurations are in ~/.pyroscope/torque.ini. <br />
{{bc|<nowiki>schedule = pyro_watchdog,30,300,"pyro.watchdog=~/.pyroscope,-v"</nowiki>}}<br />
<br />
Following steps are important. Before using pyroscope tools you have to set the missing "loaded" times to that of the .torrent file. Run this in your terminal:<br />
{{bc|<nowiki>rtcontrol '!*"*' loaded=0 -q -sname -o 'echo "$(name)s"\ntest -f "$(metafile)s" && rtxmlrpc -q d.set_custom $(hash)s tm_loaded \$(\<br />
ls -l --time-style "+%%s" "$(metafile)s" \<br />
| cut -f6 -d" ")\nrtxmlrpc -q d.save_session $(hash)s' | bash</nowiki>}}<br />
<br />
And now set the missing "completed" times to that of the data file or directory:<br />
{{bc|<nowiki>rtcontrol '!*"*' completed=0 done=100 path=\! is_ghost=no -q -sname -o 'echo "$(name)s"\ntest -e "$(realpath)s" && rtxmlrpc -q d.set_custom $(hash)s tm_completed \$(\<br />
ls -ld --time-style "+%%s" "$(realpath)s" \<br />
| cut -f6 -d" ")\nrtxmlrpc -q d.save_session $(hash)s' | bash</nowiki>}}<br />
<br />
Example usage:<br />
Will print out all torrents older than 2 hours:<br />
{{bc|<nowiki>rtcontrol -V completed=+2h -scompleted -ocompleted</nowiki>}}<br />
Deletes all torrents older than 48 hours:<br />
{{bc|<nowiki>rtcontrol -V completed=+48h -scompleted -ocompleted --cull --yes</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [http://libtorrent.rakshasa.no/rtorrent/rtorrent.1.html Manpage for rtorrent]<br />
* [[Screen Tips]]<br />
* [[Wikipedia:Comparison of BitTorrent clients|Comparison of BitTorrent clients]] on Wikipedia<br />
* [http://community.rutorrent.org/ rTorrent Community Wiki] - Public place for information on rTorrent and any project related to rTorrent, regarding setup, configuration, operations, and development.<br />
* [http://code.google.com/p/pyroscope/ PyroScope] - Collection of command line tools for rTorrent. It provides commands for creating and modifying torrent files, moving data on completion without having multiple watch folders, and mass-controlling download items via rTorrent's XML-RPC interface: searching, start/stop, deleting items with or without their data, etc. It also offers a documented [[Python]] API.<br />
* [[Rutorrent with lighttpd|ruTorrent with Lighttpd]]<br />
* [http://wiki.theaveragegeek.com/howto/installing_rtorrent_and_hellanzb_on_centos5_64-bit_vps How-to install rTorrent and Hellanzb on CentOS 5 64-bit VPS]<br />
* [http://code.google.com/p/pyroscope/wiki/DebianInstallFromSource Installation guide for rTorrent and Pryoscope on Debian] - Collection of tools for the BitTorrent protocol and especially the rTorrent client<br />
* [http://mktorrent.sourceforge.net/ mktorrent] - Command line application used to generate torrent files, which is available as {{Pkg|mktorrent}} in the [[official repositories]].<br />
* [https://github.com/kfei/docktorrent docktorrent] - Using Docker, rTorrent and ruTorrent to run a full-featured BitTorrent box.<br />
* [https://github.com/nelhage/reptyr reptyr] - another tool to take over a program's TTY (it is in the standard repos). The process may have started being attached to a terminal or to a socket in tmux, screen or dtach.<br />
* [http://caca.zoy.org/wiki/neercs neercs] - a more screen/tmux like tool than reptyr, but, like reptyr, neercs can also "steal" a process that may have started slaved to a terminal or to a socket in tmux, screen or dtach. {{AUR|neercs-git}}<br />
<br />
'''Forum threads'''<br />
* 2009-03-11 - Arch Linux - [https://bbs.archlinux.org/viewtopic.php?id=67304 HOWTO: rTorrent stats in Conky]</div>Moviurohttps://wiki.archlinux.org/index.php?title=Aria2&diff=379599Aria22015-06-21T11:34:31Z<p>Moviuro: /* Web UIs */ Web UIs are not for remote management of downloads</p>
<hr />
<div>[[Category:Internet applications]]<br />
[[it:Aria2]]<br />
From the project [http://aria2.sourceforge.net/ home page]:<br />
: ''aria2 is a lightweight multi-protocol & multi-source command-line download utility. It supports [[Wikipedia:HTTP|HTTP]]/[[Wikipedia:HTTPS|HTTPS]], [[Wikipedia:FTP|FTP]], [[Wikipedia:BitTorrent_(protocol)|BitTorrent]] and [[Wikipedia:Metalink|Metalink]]. aria2 can be manipulated via built-in [[Wikipedia:JSON-RPC|JSON-RPC]] and [[Wikipedia:XML-RPC|XML-RPC]] interfaces.''<br />
<br />
== Installation ==<br />
<br />
Install {{Pkg|aria2}} from [[official repositories]].<br />
<br />
You may also want to install [https://github.com/GutenYe/systemd-units/tree/master/aria2 aria2-systemd] to use aria2 as [[daemon]].<br />
<br />
== Execution ==<br />
<br />
The executable name for the aria2 package is {{ic|aria2c}}. This legacy naming convention has been retained for backwards compatibility.<br />
<br />
== Configuration ==<br />
<br />
=== aria2.conf ===<br />
<br />
aria2 looks to {{ic|~/.aria2/aria2.conf}} for a set of global configuration options by default. This behavior can be modified with the {{ic|--conf-path}} switch:<br />
* Download {{ic|aria2.example.rar}} using the options specified in the configuration file {{ic|/file/aria2.rapidshare}}<br />
<nowiki>$ aria2c --conf-path=/file/aria2.rapidshare http://rapidshare.com/files/12345678/aria2.example.rar</nowiki><br />
<br />
If {{ic|~/.aria2/aria2.conf}} exists and the options specified in {{ic|/file/aria2.rapidshare}} are desired, the {{ic|--no-conf}} switch must be appended to the command:<br />
* Do not use the default configuration file and download {{ic|aria2.example.rar}} using the options specified in the configuration file {{ic|/file/aria2.rapidshare}}<br />
<nowiki>$ aria2c --no-conf --conf-path=/file/aria2.rapidshare http://rapidshare.com/files/12345678/aria2.example.rar</nowiki><br />
<br />
If {{ic|~/.aria2/aria2.conf}} does not yet exist and you wish to simplify the management of configuration options:<br />
$ touch ~/.aria2/aria2.conf<br />
<br />
=== Example .bash_alias ===<br />
<br />
alias down='aria2c --conf-path=${HOME}/.aria2/aria2.conf'<br />
alias rapid='aria2c --conf-path=/file/aria2.rapidshare'<br />
<br />
=== Example aria2.conf ===<br />
<br />
{{bc|<nowiki><br />
continue<br />
dir=${HOME}/Desktop<br />
file-allocation=none<br />
input-file=${HOME}/.aria2/input.conf<br />
log-level=warn<br />
max-connection-per-server=4<br />
min-split-size=5M<br />
on-download-complete=exit<br />
</nowiki>}}<br />
<br />
This is essentially the same as if running the following:<br />
<br />
$ aria2c dir=${HOME}/Desktop file-allocation=none input-file=${HOME}/.aria2/input.conf on-download-complete=exit log-level=warn FILE<br />
<br />
{{Note|The example aria2.conf above may incorrectly use the $HOME variable. Some users have reported the curly brace syntax to explicitly create a separate ${HOME} subdirectory in the aria2 working directory. Such a directory may be difficult to traverse as bash will consider it to be the $HOME environment variable. For now, it is recommended to use absolute path names in aria2.conf.}}<br />
<br />
==== Option details ====<br />
<br />
; {{ic|continue}}: Continue downloading a partially downloaded file if a corresponding control file exists.<br />
; {{ic|<nowiki>dir=${HOME}/Desktop</nowiki>}}: Store the downloaded file(s) in {{ic|~/Desktop}}.<br />
; {{ic|<nowiki>file-allocation=none</nowiki>}}: Do not pre-allocate disk space before downloading begins. (Default: prealloc) '''<sup>1</sup>'''<br />
; {{ic|<nowiki>input-file=${HOME}/.aria2/input.conf</nowiki>}}: Download a list of line, or TAB separated URIs found in {{ic|~/.aria2/input.conf}} <br />
; {{ic|<nowiki>log-level=warn</nowiki>}}: Set log level to output warnings and errors only. (Default: debug)<br />
; {{ic|<nowiki>max-connection-per-server=4</nowiki>}}: Set a maximum of four (4) connections to each server per file. (Default: 1)<br />
; {{ic|<nowiki>min-split-size=5M</nowiki>}}: Only split the file if the size is larger than 2*5MB = 10MB. (Default: 20M)<br />
; {{ic|<nowiki>on-download-complete=exit</nowiki>}}: Run the {{ic|exit}} command and exit the shell once the download session is complete.<br />
<br />
===== Example input file #1 =====<br />
<br />
* Download {{ic|aria2-1.10.0.tar.bz2}} from two separate sources to {{ic|~/Desktop}} before merging as {{ic|aria2-1.10.0.tar.bz2}}<br />
<nowiki>http://aria2.net/files/stable/aria2-1.10.0/aria2-1.10.0.tar.bz2 http://sourceforge.net/projects/aria2/files/stable/aria2-1.10.0/aria2-1.10.0.tar.bz2</nowiki><br />
<br />
===== Example input file #2 =====<br />
<br />
* Download {{ic|aria2-1.9.5.tar.bz2}} and save to {{ic|/file/old}} as {{ic|aria2.old.tar.bz2 }} &<br />
* Download {{ic|aria2-1.10.0.tar.bz2}} and save to {{ic|~/Desktop}} as {{ic|aria2.new.tar.bz2}}<br />
<br />
<nowiki>http://aria2.net/files/stable/aria2-1.9.5/aria2-1.9.5.tar.bz2</nowiki><br />
dir=/file/old<br />
out=aria2.old.tar.bz2<br />
<nowiki>http://aria2.net/files/stable/aria2-1.10.0/aria2-1.10.0.tar.bz2</nowiki><br />
out=aria2.new.tar.bz2<br />
<br />
==== Additional notes ====<br />
<br />
; <sup>1</sup> {{ic|<nowiki>--file-allocation=falloc</nowiki>}}: Recommended for newer file systems such as ext4 (with extents support), btrfs or xfs as it allocates large files (GB) almost instantly. Do not use falloc with legacy file systems such as ext3 as prealloc consumes approximately the same amount of time as standard allocation would while locking the aria2 process from proceeding to download.<br />
<br />
{{Tip|See {{ic|<nowiki>aria2c --help=#all</nowiki>}} and the aria2 man page for a complete list of configuration options.}}<br />
<br />
=== Example aria2.rapidshare ===<br />
<br />
{{bc|<nowiki><br />
http-user=USER_NAME<br />
http-passwd=PASSWORD<br />
allow-overwrite=true<br />
dir=/file/Downloads<br />
file-allocation=falloc<br />
enable-http-pipelining=true<br />
input-file=/file/input.rapidshare<br />
log-level=error<br />
max-connection-per-server=2<br />
summary-interval=120<br />
</nowiki>}}<br />
<br />
==== Option details ====<br />
<br />
; {{ic|<nowiki>http-user=USER_NAME</nowiki>}}: Set HTTP [[Wikipedia:User_(computing)|username]] as USER_NAME for password-protected logins. This affects all [[Wikipedia:Uniform_Resource_Identifier|URIs]].<br />
; {{ic|<nowiki>http-passwd=PASSWORD</nowiki>}}: Set HTTP [[Wikipedia:Password|password]] as PASSWORD for password-protected logins. This affects all URIs.<br />
; {{ic|<nowiki>allow-overwrite=true</nowiki>}}: Restart download if a corresponding control file does not exist. (Default: false)<br />
; {{ic|<nowiki>dir=/file/Downloads</nowiki>}}: Store the downloaded file(s) in {{ic|/file/Downloads}}.<br />
; {{ic|<nowiki>file-allocation=falloc</nowiki>}}: Call [http://www.kernel.org/doc/man-pages/online/pages/man2/fallocate.2.html posix_fallocate()] to allocate disk space before downloading begins. (Default: prealloc) <br />
; {{ic|<nowiki>enable-http-pipelining=true</nowiki>}}: Enable [[Wikipedia:HTTP_Pipelining|HTTP/1.1 pipelining]] to overcome network latency and to reduce network load. (Default: false)<br />
; {{ic|<nowiki>input-file=/file/input.rapidshare</nowiki>}}: Download a list of single line of TAB separated URIs found in {{ic|/file/input.rapidshare}}<br />
; {{ic|<nowiki>log-level=error</nowiki>}}: Set log level to output errors only. (Default: debug)<br />
; {{ic|<nowiki>max-connection-per-server=2</nowiki>}}: Set a maximum of two (2) connections to each server per file. (Default: 1)<br />
; {{ic|<nowiki>summary-interval=120</nowiki>}}: Output download progress summary every 120 seconds. (Default: 60) '''<sup>3</sup>'''<br />
<br />
==== Additional notes ====<br />
<br />
* Because {{ic|aria2.rapidshare}} the contains a username and password, it is advisable to set permissions on the file to 600, or similar.<br />
<br />
$ cd /file<br />
$ chmod 600 /file/aria2.rapidshare<br />
$ ls -l<br />
total 128M<br />
-rw------- 1 arch users 167 Aug 20 00:00 aria2.rapidshare<br />
<br />
; '''<sup>3</sup>''' {{ic|<nowiki>summary-interval=0</nowiki>}}: Supresses download progress summary output and may improve overall performance. Logs will continue to be output according to the value specified in the {{ic|log-level}} option. <br />
<br />
{{Tip|The example configuration file can also be applied to [http://www.hotfile.com/ Hotfile], [http://depositfiles.com/ DepositFiles], et.al.}}<br />
{{Note|Command-line options always take precedence over options listed in a configuration file.}}<br />
<br />
=== Example aria2.bittorrent ===<br />
<br />
{{bc|<nowiki><br />
bt-seed-unverified<br />
max-overall-upload-limit=1M<br />
max-upload-limit=128K<br />
seed-ratio=5.0<br />
seed-time=240<br />
</nowiki>}}<br />
<br />
==== Option details ====<br />
<br />
; {{ic|<nowiki>bt-seed-unverified=false</nowiki>}}: Do not check the hash of the file(s) before seeding. (Default: true)<br />
; {{ic|<nowiki>max-overall-upload-limit=1M</nowiki>}}: Set maximum overall upload speed to 1MB/sec. (Default: 0)<br />
; {{ic|<nowiki>max-upload-limit=128K</nowiki>}}: Set maximum upload speed per torrent to 128K/sec. (Default: 0)<br />
; {{ic|<nowiki>seed-ratio=5.0</nowiki>}}: Seed completed torrents until share ratio reaches 5.0. (Default: 1.0)<br />
; {{ic|<nowiki>seed-time=240</nowiki>}}: Seed completed torrents for 240 minutes.<br />
<br />
{{Note|If both {{ic|seed-ratio}} and {{ic|seed-time}} are specified, seeding ends when at least one of the conditions is satisfied.}}<br />
<br />
=== Example aria2.daemon ===<br />
<br />
This configuration can be used to start Aria2 as a service. It can be used in conjunction with several of the frontends listed below. Note that rpc-user and rpc-pass are deprecated, but most frontends have not been ported to the new authentication yet. Do not forget to change user, password and Download directory.<br />
<br />
{{bc|<nowiki><br />
continue<br />
daemon=true<br />
dir=/home/aria2/Downloads<br />
file-allocation=falloc<br />
log-level=warn<br />
max-connection-per-server=4<br />
max-concurrent-downloads=3<br />
max-overall-download-limit=0<br />
min-split-size=5M<br />
enable-http-pipelining=true<br />
<br />
enable-rpc=true<br />
rpc-listen-all=true<br />
rpc-user=rpcuser<br />
rpc-passwd=rpcpass<br />
</nowiki>}}<br />
<br />
== Frontends ==<br />
<br />
{{note|Settings implemented in frontends do not affect {{ic|aria2}}'s own configuration, and it is uncertain whether the different UIs reuse {{ic|aria2}} configuration if a custom one has been made. Users should ensure their desired parameters are effectively implemented within selected tools and that they are stored persistently (uGet for example has its own {{ic|aria2}}'s command line which sticks across reboots).}}<br />
<br />
=== Web UIs ===<br />
{{note|These frontends need {{ic|aria2c}} to be started with {{ic|--enable-rpc}} in order to work.}}<br />
{{note|These are meant to run on your local computer, not on a remote server that downloads using aria}}<br />
* {{App|YaaW|Yet Another Aria2 Web Frontend in pure HTML/CSS/Javascirpt.|https://github.com/binux/yaaw|{{AUR|yaaw-git}}}}<br />
* {{App|Webui|Html frontend for aria2.|https://github.com/ziahamza/webui-aria2|{{AUR|webui-aria2}}}}<br />
* {{App|aria2rpc|Command line tool for connecting to a remote instance of {{ic|aria2c}}. If {{ic|aria2c}} is installed it can be found under {{ic|/usr/share/doc/aria2/xmlrpc/aria2rpc}}.|https://github.com/tatsuhiro-t/aria2/blob/master/doc/xmlrpc/aria2rpc|{{Pkg|aria2}}}}<br />
<br />
=== Other UIs ===<br />
{{note|These frontends '''do not need''' {{ic|aria2c}} to be started with {{ic|--enable-rpc}} to function.}}<br />
<br />
* {{App|aria2fe|A GUI for the CLI-based aria2 download utility.|http://sourceforge.net/projects/aria2fe/|{{AUR|aria2fe}}}}<br />
* {{App|Diana|Command line tool for aria2|https://github.com/baskerville/diana|{{AUR|diana-git}}}}<br />
* {{App|downloadm|A download accelerator/manager which uses aria2c as a backend.|http://sourceforge.net/projects/downloadm/|{{AUR|downloadm}}}}<br />
* {{App|eatmonkey|Download manager for Xfce that works with aria2.|http://goodies.xfce.org/projects/applications/eatmonkey|{{AUR|eatmonkey}}}}<br />
* {{App|karia2|QT4 interface for aria2 download mananger.|http://sourceforge.net/projects/karia2/|{{AUR|karia2-svn}}}}<br />
* {{App|uGet|Feature-rich GTK+/CLI download manager which can use aria2 as a back-end by enabling a built-in plugin.|http://ugetdm.com|{{Pkg|uget}}}} <br />
* {{App|yaner|GTK+ interface for aria2 download mananger.|http://iven.github.com/Yaner|{{AUR|yaner-git}}}}<br />
<br />
It is convenient to append a monitor function based on diana in your shell configuration file:<br />
{{bc|<nowiki><br />
da(){<br />
watch -ctn 1 "(echo -e '\033[32mGID\t\t Name\t\t\t\t\t\t\t%\tDown\tSize\tSpeed\tUp\tS/L\tTime\033[36m'; \<br />
diana list| cut -c -112; echo -e '\033[37m'; diana stats)"<br />
}<br />
</nowiki>}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Download the packages without installing them ===<br />
<br />
Just use the command below:<br />
<br />
# pacman -Sp packages | aria2c -i -<br />
<br />
{{Ic|pacman -Sp}} lists the urls of the packages on stdout, instead of downloading them, then {{Ic|<nowiki>|</nowiki>}} pipes it to the next command. Finally, The {{Ic|-i}} in {{Ic|aria2c -i -}} switch to aria2c means that the urls for files to be downloaded should be read from the file specified, but if {{Ic|-}} is passed, then read the urls from stdin.<br />
<br />
=== pacman XferCommand ===<br />
<br />
aria2 can be used as the default download manager for the [[pacman]] package manager. See the ArchWiki article [[Improve pacman performance]] for additional details.<br />
<br />
=== Custom minimal build ===<br />
<br />
Gains in application response can be gleaned by removing unused features and protocols. Further gains can be accomplished by removing support for external libraries with a custom build. Available options are visible through {{ic|./configure --help}}. See the [[Arch Build System]] page for further details.<br />
<br />
=== aria2 sometimes stops downloading without exiting ===<br />
<br />
You can use this little script to restart the download every 30 minutes:<br />
<br />
{{bc|<nowiki><br />
#!/bin/bash<br />
<br />
if [ ! -x /usr/bin/aria2c ]; then<br />
echo "aria2c is not installed"<br />
exit 1<br />
fi<br />
<br />
if [ ! -d ~/.torrentdl ]; then<br />
mkdir ~/.torrentdl<br />
fi<br />
<br />
while :; do<br />
for i in $@; do<br />
MAGNET=false<br />
if [[ "$i" = magnet* ]]; then<br />
MAGNET=true<br />
elif [ ! -f "$i" ]; then<br />
echo "The file ('$i') is not given or does not exist"<br />
exit 1<br />
fi<br />
if ! aria2c --hash-check-only=true "$i" &> /dev/null; then<br />
aria2c "$i"<br />
sleep 30m && kill -9 $(pidof aria2c)<br />
else<br />
echo "Torrent is downloaded!"<br />
fi<br />
done<br />
done<br />
</nowiki>}}<br />
<br />
=== Start aria2c on system boot ===<br />
<br />
{{Accuracy|Possible "failed to bind errors" indicate towards a race condition, requires/after and similar should be updated accordingly}}<br />
<br />
Save the following [[systemd]] service file, adjust username and config path according to your setup. Ensure your config is set to deamonize (use {{ic|1=daemon=true}}).<br />
<br />
{{hc|/etc/systemd/system/aria2c.service|<nowiki><br />
[Unit]<br />
Description=Aria2c download manager<br />
After=network.target<br />
<br />
[Service]<br />
User=aria2<br />
Type=forking<br />
ExecStart=/usr/bin/aria2c --conf-path=/home/aria2/.aria2/aria2.daemon<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
Then [[systemd#Using units|start and/or enable]] the service.<br />
<br />
=== Changing the User Agent ===<br />
<br />
Some sites may filter the requests based on your User Agent, since Aria2 is not a well known downloader, it may be good to use a most known downloader or browser as the Aria's User Agent. Just use the -U option like this:<br />
<br />
$ aria2c -UWget <nowiki>http://some-url-to-download/file.xyz</nowiki><br />
<br />
You can use whatever you want, like '''-UMozilla/5.0''' and so on.<br />
<br />
== See also ==<br />
<br />
* [http://sourceforge.net/apps/trac/aria2/wiki aria2 wiki] - Official site<br />
* [http://sourceforge.net/apps/trac/aria2/wiki/UsageExample aria2 usage examples] - Official site<br />
* [http://gotux.net/arch-linux/aria2c-downloader-through-vpn-tunnel/ aria2c downloader through VPN tunnel] - Unofficial site</div>Moviurohttps://wiki.archlinux.org/index.php?title=Talk:Duplicity&diff=368152Talk:Duplicity2015-04-01T10:19:38Z<p>Moviuro: /* Server setup */ shell</p>
<hr />
<div>= Server setup =<br />
Hi all, I'm trying to create a secure server for duplicity: any hints on how to make it secure? Like, imposing limits with quotas (on e.g. BTRFS), bandwidth limits, '''no remote shell''' (really the one thing I don't get how to do) when using a reasonable protocol (not ftp)? I tried looking on internet, but everyone is more concerned about "how do I make it work" instead of "how do I make it secure"?<br />
<br />
It'll also be a good addition to the wiki page IMO<br />
<br />
Cheers, [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 22:13, 31 March 2015 (UTC)<br />
: if you use the following "shell", SSH access to the server will be regulated (POSIX compliant, as a bonus)<br />
#!/bin/sh<br />
if [ $# -eq 0 ]; then<br />
printf "%s\n" "Hahaha, you fool"<br />
printf "%s\n" "Only rsync(1) will ever work here."<br />
exit 1<br />
elif [ $# -eq 2 ] && [ "$1" = "-c" ] && printf %s\\n "$2" | grep -qe "^rsync --server"; then<br />
exec $2<br />
fi</div>Moviurohttps://wiki.archlinux.org/index.php?title=Talk:Duplicity&diff=368059Talk:Duplicity2015-03-31T22:13:57Z<p>Moviuro: what about a secure server setup?</p>
<hr />
<div>= Server setup =<br />
Hi all, I'm trying to create a secure server for duplicity: any hints on how to make it secure? Like, imposing limits with quotas (on e.g. BTRFS), bandwidth limits, '''no remote shell''' (really the one thing I don't get how to do) when using a reasonable protocol (not ftp)? I tried looking on internet, but everyone is more concerned about "how do I make it work" instead of "how do I make it secure"?<br />
<br />
It'll also be a good addition to the wiki page IMO<br />
<br />
Cheers, [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 22:13, 31 March 2015 (UTC)</div>Moviurohttps://wiki.archlinux.org/index.php?title=Unbound&diff=367221Unbound2015-03-26T09:41:20Z<p>Moviuro: /* DNSSEC validation */ Adding tests</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[https://unbound.net/ Unbound] is a validating, recursive, and caching DNS resolver.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|unbound}} package from [[official repositories]].<br />
<br />
Additionally, {{Pkg|expat}} is required for [[DNSSEC]] validation.<br />
<br />
== Configuration ==<br />
<br />
''unbound'' is easy to configure. There is a sample config file {{ic|/etc/unbound/unbound.conf.example}}, which can be copied to {{ic|/etc/unbound/unbound.conf}} and with the adjustments to the file for your own needs it is enough to run on both IPv4 and IPv6 without access restrictions.<br />
<br />
=== Access control ===<br />
<br />
You can specify the interfaces to answer queries from by IP address. To listen on ''localhost'', use:<br />
<br />
interface: 127.0.0.1<br />
<br />
To listen on all interfaces, use:<br />
<br />
interface: 0.0.0.0<br />
<br />
Access can be further configured via the {{ic|access-control}} option:<br />
<br />
access-control: ''subnet'' ''action''<br />
<br />
For example:<br />
<br />
access-control: 192.168.1.0/24 allow<br />
<br />
''action'' can be one of {{ic|deny}} (drop message), {{ic|refuse}} (polite error reply), {{ic|allow}} (recursive ok), or {{ic|allow_snoop}} (recursive and nonrecursive ok). By default everything is refused except for localhost.<br />
<br />
=== Root hints ===<br />
<br />
For querying a host that is not cached as an address the resolver needs to start at the top of the server tree and query the root servers to know where to go for the top level domain for the address being queried. Therefore it is necessary to put a ''root hints'' file into the ''unbound'' config directory. The simplest way to do this is to run the command:<br />
<br />
{{bc|<nowiki># wget ftp://FTP.INTERNIC.NET/domain/named.cache -O /etc/unbound/root.hints</nowiki>}}<br />
<br />
It is a good idea to run this every six months or so in order to make sure the list of root servers is up to date. This can be done manually or by setting up a [[cron]] job for the task.<br />
<br />
Point ''unbound'' to the {{ic|root.hints}} file:<br />
<br />
root-hints: "/etc/unbound/root.hints"<br />
<br />
=== Set /etc/resolv.conf to use the local DNS server ===<br />
<br />
Edit {{ic|/etc/resolv.conf}} (See also [[resolv.conf]]):<br />
<br />
nameserver 127.0.0.1<br />
<br />
Also if you want to be able to use the hostname of local machine names without the fully qualified domain names, then add a line with the local domain such as:<br />
<br />
domain localdomain.com<br />
nameserver 127.0.0.1<br />
<br />
That way you can refer to local hosts such as mainmachine1.localdomain.com as simply mainmachine1 when using the ssh command, but the drill command below still requires the fully qualified domain names in order to perform lookups.<br />
<br />
Testing the server before making it default can be done using the drill command from the {{Pkg|ldns}} package with examples from internal and external forward and reverse addresses:<br />
<br />
$ drill @127.0.0.1 www.cnn.com<br />
$ drill @127.0.0.1 localmachine.localdomain.com<br />
$ drill @127.0.0.1 -x w.x.y.z <br />
<br />
where {{ic|w.x.y.z}} can be a local or external IP address and the {{ic|-x}} option requests a reverse lookup. Once all is working, and you have {{ic|/etc/resolv.conf}} set to use {{ic|127.0.0.1}} as the nameserver then you no longer need the {{ic|@127.0.0.1}} in the ''drill'' command, and you can test again that it uses the default DNS server - check that the server used as listed at the bottom of the output from each of these commands shows it is {{ic|127.0.0.1}} being queried.<br />
<br />
=== Logging ===<br />
<br />
If you will want logging for ''unbound'', then create a log file which can also be in the same directory, but you can choose any location. One way is then to do as root:<br />
<br />
# touch /etc/unbound/unbound.log<br />
# chown unbound:unbound /etc/unbound/unbound.log<br />
<br />
Then you can include the logging parameter when you set up the main {{ic|unbound.conf}} file as below.<br />
<br />
=== DNSSEC validation ===<br />
<br />
You will need the root server trust key anchor file. It is provided by the {{Pkg|dnssec-anchors}} package (already installed as a dependency), however, ''unbound'' needs read and write access to the file. You can follow an example configuration below: <br />
<br />
# mkdir /etc/unbound/keys<br />
# cp /etc/trusted-key.key /etc/unbound/keys/dnssec-root-anchor.key<br />
# chown -R unbound:unbound /etc/unbound/keys<br />
<br />
Then point ''unbound'' to the file:<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
server:<br />
auto-trust-anchor-file: "/etc/unbound/keys/dnssec-root-anchor.key"<br />
...<br />
}}<br />
<br />
Also make sure that if a general [[#Forwarding queries|forward]] to the Google servers had been in place, then comment them out otherwise DNS queries will fail. DNSSEC validation will be done if the DNS server being queried supports it.<br />
<br />
{{Note|Including DNSSEC checking significantly increases DNS lookup times for initial lookups. Once an address is cached locally, then the lookup is virtually instantaneous.}}<br />
<br />
You can now test if DNSSEC is working, using ''drill'' in {{Pkg|ldns}} (installed as dependency):<br />
<br />
drill sigfail.verteiltesysteme.net # should return rcode: SERVFAIL<br />
drill sigok.verteiltesysteme.net # should return rcode: NOERROR<br />
<br />
=== Forwarding queries ===<br />
<br />
If you have a local network which you wish to have DNS queries for and there is a local DNS server that you would like to forward queries to then you should include this line:<br />
<br />
private-address: ''local_subnet/subnet_mask''<br />
<br />
for example:<br />
<br />
private-address: 10.0.0.0/24<br />
<br />
To include a local DNS server for both forward and reverse local addresses a set of lines similar to these below is necessary with a forward and reverse lookup (choose the IP address of the server providing DNS for the local network accordingly by changing 10.0.0.1 in the lines below):<br />
<br />
local-zone: "10.in-addr.arpa." transparent<br />
<br />
This line above is important to get the reverse lookup to work correctly.<br />
<br />
forward-zone:<br />
name: "mynetwork.com."<br />
forward-addr: 10.0.0.1 # Home DNS<br />
<br />
forward-zone:<br />
name: "10.in-addr.arpa."<br />
forward-addr: 10.0.0.1<br />
<br />
{{Note|There is a difference between forward zones and stub zones - stub zones will only work when connected to an authoritative DNS server directly. This would work for lookups from a [[bind]] DNS server if it is providing authoritative DNS - but if you are referring queries to an ''unbound'' server in which internal lookups are forwarded on to another DNS server, then defining the referral as a stub zone in the machine here will not work. In that case it is necessary to define a forward zone as above, since forward zones can have daisy chain lookups onward to other DNS servers. i.e. forward zones can refer queries to recursive DNS servers. This distinction is important as you do not get any error messages indicating what the problem is if you use a stub zone inappropriately.}}<br />
<br />
You can set up the localhost forward and reverse lookups with the following lines:<br />
<br />
local-zone: "localhost." static<br />
local-data: "localhost. 10800 IN NS localhost."<br />
local-data: "localhost. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"<br />
local-data: "localhost. 10800 IN A 127.0.0.1"<br />
local-zone: "127.in-addr.arpa." static<br />
local-data: "127.in-addr.arpa. 10800 IN NS localhost."<br />
local-data: "127.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 2 3600 1200 604800 10800"<br />
local-data: "1.0.0.127.in-addr.arpa. 10800 IN PTR localhost."<br />
<br />
Then to use specific servers for default forward zones that are outside of the local machine and outside of the local network (i.e. all other queries will be forwarded to them, and then cached) add this to the configuration file (and in this example the first two addresses are the fast google DNS servers):<br />
<br />
forward-zone:<br />
name: "."<br />
forward-addr: 8.8.8.8<br />
forward-addr: 8.8.4.4<br />
forward-addr: 208.67.222.222<br />
forward-addr: 208.67.220.220<br />
<br />
This will make ''unbound'' use Google and OpenDNS servers as the forward zone for external lookups.<br />
<br />
{{Note|OpenDNS strips DNSSEC records from responses. Do not use the above forward zone if you want to enable [[#DNSSEC validation]].}}<br />
<br />
== Usage ==<br />
<br />
=== Starting Unbound ===<br />
<br />
The ''unbound'' package provides {{ic|unbound.service}}, just [[systemd#Using units|start]] it. You may want to ''enable'' it so that it starts at boot.<br />
<br />
=== Remotely control Unbound ===<br />
<br />
''unbound'' ships with the {{ic|unbound-control}} utility which enables us to remotely administer the unbound server. It is similar to the [[Pdnsd#pdnsd-ctl|pdnsd-ctl]] command of {{Pkg|pdnsd}}.<br />
<br />
==== Setting up unbound-control ====<br />
<br />
Before you can start using it, the following steps need to be performed:<br />
<br />
1) Firstly, you need to run the following command<br />
<br />
# unbound-control-setup<br />
<br />
which will generate a self-signed certificate and private key for the server, as well as the client. These files will be created in the {{ic|/etc/unbound}} directory.<br />
<br />
2) After that, edit {{ic|/etc/unbound/unbound.conf}} and put the following contents in that. The '''control-enable: yes''' option is necessary, the rest can be adjusted as required.<br />
<br />
remote-control:<br />
# Enable remote control with unbound-control(8) here.<br />
# set up the keys and certificates with unbound-control-setup.<br />
control-enable: yes<br />
<br />
# what interfaces are listened to for remote control.<br />
# give 0.0.0.0 and ::0 to listen to all interfaces.<br />
control-interface: 127.0.0.1<br />
<br />
# port number for remote control operations.<br />
control-port: 8953<br />
<br />
# unbound server key file.<br />
server-key-file: "/etc/unbound/unbound_server.key"<br />
<br />
# unbound server certificate file.<br />
server-cert-file: "/etc/unbound/unbound_server.pem"<br />
<br />
# unbound-control key file.<br />
control-key-file: "/etc/unbound/unbound_control.key"<br />
<br />
# unbound-control certificate file.<br />
control-cert-file: "/etc/unbound/unbound_control.pem"<br />
<br />
==== Using unbound-control ====<br />
<br />
Some of the commands that can be used with ''unbound-control'' are:<br />
<br />
* print statistics without resetting them<br />
# unbound-control stats_noreset<br />
<br />
* dump cache to stdout<br />
# unbound-control dump_cache<br />
<br />
* flush cache and reload configuration<br />
# unbound-control reload<br />
<br />
Please refer to {{ic|man 8 unbound-control}} for a detailed look at the operations it supports.<br />
<br />
== Adding an authoritative DNS server ==<br />
<br />
For users who wish to run both a validating, recursive, caching DNS server as well as an authoritative DNS server on a single machine then it may be useful to refer to the wiki page [[nsd]] which gives an example of a configuration for such a system. Having one server for authoritative DNS queries and a separate DNS server for the validating, recursive, caching DNS functions gives increased security over a single DNS server providing all of these functions. Many users have used bind as a single DNS server, and some help on migration from bind to the combination of running nsd and bind is provided in the [[nsd]] wiki page.<br />
<br />
== WAN facing DNS ==<br />
<br />
It is also possible to change the configuration files and interfaces on which the server is listening so that DNS queries from machines outside of the local network can access specific machines within the LAN. This is useful for web and mail servers which are accessible from anywhere, and the same techniques can be employed as has been achieved using bind for many years, in combination with suitable port forwarding on firewall machines to forward incoming requests to the right machine.<br />
<br />
== Issues concerning num-threads ==<br />
<br />
The man page for {{ic|unbound.conf}} mentions:<br />
<br />
outgoing-range: <number><br />
Number of ports to open. This number of file descriptors can be opened per thread.<br />
<br />
and some sources suggest that the {{ic|num-threads}} parameter should be set to the number of cpu cores. The sample {{ic|unbound.conf.example}} file merely has:<br />
<br />
# number of threads to create. 1 disables threading.<br />
# num-threads: 1<br />
<br />
However it is not possible to arbitrarily increase {{ic|num-threads}} above {{ic|1}} without causing ''unbound'' to start with warnings in the logs about exceeding the number of file descriptors. In reality for most users running on small networks or on a single machine it should be unnecessary to seek performance enhancement by increasing {{ic|num-threads}} above {{ic|1}}. If you do wish to do so then refer to [http://www.unbound.net/documentation/howto_optimise.html official documentation] and the following rule of thumb should work:<br />
<br />
:''Set {{ic|num-threads}} equal to the number of CPU cores on the system. E.g. for 4 CPUs with 2 cores each, use 8.''<br />
<br />
Set the {{ic|outgoing-range}} to as large a value as possible, see the sections in the referred web page above on how to overcome the limit of {{ic|1024}} in total. This services more clients at a time. With 1 core, try {{ic|950}}. With 2 cores, try {{ic|450}}. With 4 cores try {{ic|200}}. The {{ic|num-queries-per-thread}} is best set at half the number of the {{ic|outgoing-range}}. <br />
<br />
Because of the limit on {{ic|outgoing-range}} thus also limits {{ic|num-queries-per-thread}}, it is better to compile with {{Pkg|libevent}}, so that there is no {{ic|1024}} limit on {{ic|outgoing-range}}. If you need to compile this way for a heavy duty DNS server then you will need to compile the programme from source instead of using the {{Pkg|unbound}} package.<br />
<br />
== See also ==<br />
<br />
* [https://github.com/jodrell/unbound-block-hosts/ Block hosts that contain advertisements]</div>Moviurohttps://wiki.archlinux.org/index.php?title=Talk:Systemd-boot&diff=366848Talk:Systemd-boot2015-03-23T15:28:31Z<p>Moviuro: /* About reboot into firmware configuration interface */</p>
<hr />
<div>== Some questions ==<br />
<br />
1) Is it normal that article "strongly recommends" to mount your ESP to /boot if you use gummiboot? Because I cannot see differences with other bootloaders. For example, EFISTUB article contains a whole section to explain [[EFISTUB#Alternative ESP Mount Points]].<br />
<br />
2) Do we need to add Warning about windows [https://bbs.archlinux.org/viewtopic.php?id=193581 Sistematically corrupts] linux boot files on esp?<br />
<br />
3) And also, do we need to add [http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html such] graphical tutorial link for Fast Startup windows setting or maybe it is too ugly for being in ArchWiki?<br />
<br />
— [[User:Agent0|Agent0]] ([[User_talk:Agent0|talk]]|[[Special:Contributions/Agent0|contribs]]) 02:12, 19 February 2015 (UTC)<br />
<br />
:1) I think a reason for that mount is what is described in [[Gummiboot#Updating]]. We could move that paragraph up to follow the "strongly recommends" to make it more prominent? <br />
:2) We have [[Windows_and_Arch_dual_boot#Fast_Start-Up]] (and funnily the author had the same idea as you in (3) and linked exactly that). But I totally agree we should have a crosslink to that dual boot section to warn users in this article. Regarding the bbs thread: Did you experience another corruption after disabling it? If yes, we definetely need to follow it up. <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 08:39, 19 February 2015 (UTC)<br />
<br />
== About reboot into firmware configuration interface ==<br />
If I remember correctly, isn't that one of the entries that are auto-generated by gummiboot, along with windows entries? [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 12:41, 15 March 2015 (UTC)<br />
: AFAIK, there aren't any autogenerated default options in the Gummiboot boot manager to reboot into the firmware. I only have the autodetected {{ic|efiboomgr}} entry which appears when Windows is installed and the entries I defined manually. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 13:08, 15 March 2015 (UTC)<br />
: I spent some time googleing about this issue. Without success. So it would save time and pain to add some working example. It's a useful feature. --[[User:Cschlote|Cschlote]] ([[User talk:Cschlote|talk]]) 00:26, 16 March 2015 (UTC)<br />
:: http://wstaw.org/w/3gSV/ And I don't have a Reboot into device firmware entry, nor the EFI default loader [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 22:35, 21 March 2015 (UTC)<br />
::: I already found several real machines, which will either show none of these entries, or just one of them. Only a VM shows all entries. --[[User:Cschlote|Cschlote]] ([[User talk:Cschlote|talk]]) 12:32, 23 March 2015 (UTC)<br />
:::: Well, this picture was taken on my Dell Latitude (E6430). [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 15:28, 23 March 2015 (UTC)</div>Moviurohttps://wiki.archlinux.org/index.php?title=Talk:Systemd-boot&diff=366626Talk:Systemd-boot2015-03-21T22:35:49Z<p>Moviuro: /* About reboot into firmware configuration interface */</p>
<hr />
<div>== Some questions ==<br />
<br />
1) Is it normal that article "strongly recommends" to mount your ESP to /boot if you use gummiboot? Because I cannot see differences with other bootloaders. For example, EFISTUB article contains a whole section to explain [[EFISTUB#Alternative ESP Mount Points]].<br />
<br />
2) Do we need to add Warning about windows [https://bbs.archlinux.org/viewtopic.php?id=193581 Sistematically corrupts] linux boot files on esp?<br />
<br />
3) And also, do we need to add [http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html such] graphical tutorial link for Fast Startup windows setting or maybe it is too ugly for being in ArchWiki?<br />
<br />
— [[User:Agent0|Agent0]] ([[User_talk:Agent0|talk]]|[[Special:Contributions/Agent0|contribs]]) 02:12, 19 February 2015 (UTC)<br />
<br />
:1) I think a reason for that mount is what is described in [[Gummiboot#Updating]]. We could move that paragraph up to follow the "strongly recommends" to make it more prominent? <br />
:2) We have [[Windows_and_Arch_dual_boot#Fast_Start-Up]] (and funnily the author had the same idea as you in (3) and linked exactly that). But I totally agree we should have a crosslink to that dual boot section to warn users in this article. Regarding the bbs thread: Did you experience another corruption after disabling it? If yes, we definetely need to follow it up. <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 08:39, 19 February 2015 (UTC)<br />
<br />
== About reboot into firmware configuration interface ==<br />
If I remember correctly, isn't that one of the entries that are auto-generated by gummiboot, along with windows entries? [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 12:41, 15 March 2015 (UTC)<br />
: AFAIK, there aren't any autogenerated default options in the Gummiboot boot manager to reboot into the firmware. I only have the autodetected {{ic|efiboomgr}} entry which appears when Windows is installed and the entries I defined manually. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 13:08, 15 March 2015 (UTC)<br />
: I spent some time googleing about this issue. Without success. So it would save time and pain to add some working example. It's a useful feature. --[[User:Cschlote|Cschlote]] ([[User talk:Cschlote|talk]]) 00:26, 16 March 2015 (UTC)<br />
:: http://wstaw.org/w/3gSV/ And I don't have a Reboot into device firmware entry, nor the EFI default loader [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 22:35, 21 March 2015 (UTC)</div>Moviurohttps://wiki.archlinux.org/index.php?title=Talk:Systemd-boot&diff=366612Talk:Systemd-boot2015-03-21T21:37:45Z<p>Moviuro: /* About reboot into firmware configuration interface */</p>
<hr />
<div>== Some questions ==<br />
<br />
1) Is it normal that article "strongly recommends" to mount your ESP to /boot if you use gummiboot? Because I cannot see differences with other bootloaders. For example, EFISTUB article contains a whole section to explain [[EFISTUB#Alternative ESP Mount Points]].<br />
<br />
2) Do we need to add Warning about windows [https://bbs.archlinux.org/viewtopic.php?id=193581 Sistematically corrupts] linux boot files on esp?<br />
<br />
3) And also, do we need to add [http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html such] graphical tutorial link for Fast Startup windows setting or maybe it is too ugly for being in ArchWiki?<br />
<br />
— [[User:Agent0|Agent0]] ([[User_talk:Agent0|talk]]|[[Special:Contributions/Agent0|contribs]]) 02:12, 19 February 2015 (UTC)<br />
<br />
:1) I think a reason for that mount is what is described in [[Gummiboot#Updating]]. We could move that paragraph up to follow the "strongly recommends" to make it more prominent? <br />
:2) We have [[Windows_and_Arch_dual_boot#Fast_Start-Up]] (and funnily the author had the same idea as you in (3) and linked exactly that). But I totally agree we should have a crosslink to that dual boot section to warn users in this article. Regarding the bbs thread: Did you experience another corruption after disabling it? If yes, we definetely need to follow it up. <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 08:39, 19 February 2015 (UTC)<br />
<br />
== About reboot into firmware configuration interface ==<br />
If I remember correctly, isn't that one of the entries that are auto-generated by gummiboot, along with windows entries? [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 12:41, 15 March 2015 (UTC)<br />
: AFAIK, there aren't any autogenerated default options in the Gummiboot boot manager to reboot into the firmware. I only have the autodetected {{ic|efiboomgr}} entry which appears when Windows is installed and the entries I defined manually. -- [[User:wget|wget]] ([[User talk:wget|talk]]) 13:08, 15 March 2015 (UTC)<br />
: I spent some time googleing about this issue. Without success. So it would save time and pain to add some working example. It's a useful feature. --[[User:Cschlote|Cschlote]] ([[User talk:Cschlote|talk]]) 00:26, 16 March 2015 (UTC)<br />
:: http://wstaw.org/w/3gSV/ And I don't have a Reboot into device firmware entry [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 21:37, 21 March 2015 (UTC)</div>Moviurohttps://wiki.archlinux.org/index.php?title=Talk:Systemd-boot&diff=365528Talk:Systemd-boot2015-03-15T12:41:16Z<p>Moviuro: About reboot into firmware configuration interface</p>
<hr />
<div>== Some questions ==<br />
<br />
1) Is it normal that article "strongly recommends" to mount your ESP to /boot if you use gummiboot? Because I cannot see differences with other bootloaders. For example, EFISTUB article contains a whole section to explain [[EFISTUB#Alternative ESP Mount Points]].<br />
<br />
2) Do we need to add Warning about windows [https://bbs.archlinux.org/viewtopic.php?id=193581 Sistematically corrupts] linux boot files on esp?<br />
<br />
3) And also, do we need to add [http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html such] graphical tutorial link for Fast Startup windows setting or maybe it is too ugly for being in ArchWiki?<br />
<br />
— [[User:Agent0|Agent0]] ([[User_talk:Agent0|talk]]|[[Special:Contributions/Agent0|contribs]]) 02:12, 19 February 2015 (UTC)<br />
<br />
:1) I think a reason for that mount is what is described in [[Gummiboot#Updating]]. We could move that paragraph up to follow the "strongly recommends" to make it more prominent? <br />
:2) We have [[Windows_and_Arch_dual_boot#Fast_Start-Up]] (and funnily the author had the same idea as you in (3) and linked exactly that). But I totally agree we should have a crosslink to that dual boot section to warn users in this article. Regarding the bbs thread: Did you experience another corruption after disabling it? If yes, we definetely need to follow it up. <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 08:39, 19 February 2015 (UTC)<br />
<br />
== About reboot into firmware configuration interface ==<br />
If I remember correctly, isn't that one of the entries that are auto-generated by gummiboot, along with windows entries? [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 12:41, 15 March 2015 (UTC)</div>Moviurohttps://wiki.archlinux.org/index.php?title=Talk:Android&diff=363320Talk:Android2015-03-01T21:12:40Z<p>Moviuro: /* Android SDK core components */</p>
<hr />
<div>I'll leave this here until I get enough time to put the changes in the wiki page: http://forum.xda-developers.com/showthread.php?t=2259929<br />
[[User:GermainZ|GermainZ]] ([[User talk:GermainZ|talk]]) 18:45, 4 May 2013 (UTC)<br />
<br />
== Eclipse ==<br />
<br />
I found installing the Android SDK within Eclipse is much more pleasant,<br />
especially when your developing alone. No need for AUR and chmod orgies.<br />
<br />
Open up Eclipse, go to Help - Install new Software - Add...<br />
<br />
enter <br />
https://dl-ssl.google.com/android/eclipse/<br />
<br />
and choose "Developer Tools"<br />
<br />
In my case everything was installed to<br />
<br />
~/Development/android-sdks<br />
(of course the installer lets you choose any directory that suits you best)<br />
<br />
After that, close eclipse,<br />
<br />
cd ~/Development/android-sdks/tools and fire up the Android SDK Manager ./android sdk<br />
<br />
to get additional libs and the latest updates (don't miss this step)<br />
<br />
You can now create a new Android project in Eclipse and everything works fine!<br />
<br />
[[User:Goodboy|Goodboy]] ([[User talk:Goodboy|talk]]) 14:46, 6 July 2013 (UTC)<br />
<br />
== Java/OpenJDK ==<br />
<br />
I always build with no problems Android using OpenJDK. I think it was OpenJDK 7, but I'm going to build Android again so I'll see which one works best.<br />
Anyway there's no need to use Oracle Java.<br />
<br />
As of November 3/4, 2014 with the release of Android 5.0, Android will no longer build with Oracle Java. (I remember reading this somewhere on the internet and this was also my experience when trying to build 5.0 with Oracle Java. After switching to OpenJDK 7 there were no build issues related to java. [[User:Orkeren|Orkeren]] ([[User talk:Orkeren|talk]]) 21:26, 4 November 2014 (UTC)<br />
<br />
== Android SDK core components ==<br />
<br />
Find the line where it says:<br />
# chown -R :sdkusers /opt/android-sdk/<br />
<br />
And should be like this:<br />
# chown -R <user>:sdkusers /opt/android-sdk/<br />
You must change it from root user to your regular user, otherwise it just won't let you edit anything at {{ic|/opt/android-sdk/}}. Who da heck changed it? I've already tested it in the past.<br />
<br />
: I did, because it makes no sense to put a particular user in charge (and, it '''is''' the point of groups). I also added that you should use {{ic|chmod -R g+w}} afterwards to have it working. [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 13:44, 1 March 2015 (UTC)<br />
:: Umm ok. I wonder how I didn't notice {{ic|chmod -R g+w}} part? Well, nevermind, great work. Thanks sir ;)<br />
::: Most welcome ;) Don't forget to sign, though... (with 4 tildes) [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 21:12, 1 March 2015 (UTC)</div>Moviurohttps://wiki.archlinux.org/index.php?title=Android&diff=363284Android2015-03-01T14:07:26Z<p>Moviuro: /* Android SDK core components */ minor corrections to reflect what the commands do</p>
<hr />
<div>[[Category:Development]]<br />
[[Category:Mobile devices]]<br />
[[it:Android]]<br />
[[ja:Android]]<br />
[[ru:Android]]<br />
[[zh-CN:Android]]<br />
{{Related articles start}}<br />
{{Related|Android notifier}}<br />
{{Related|Android tethering}}<br />
{{Related articles end}}<br />
<br />
== Exploring Android device ==<br />
<br />
There are few methods of exploring your device:<br />
<br />
*[[MTP]] over USB for files transferring.<br />
*[[#Connecting to a real device - Android Debug Bridge (ADB)|ADB/Fastboot]] for development purposes.<br />
*[[#Alternative connection methods|Alternative methods]] (such as FTP, SSH).<br />
<br />
== Android development ==<br />
<br />
There are 3 steps that need to be performed before you can develop Android applications on your Arch Linux box:<br />
<br />
# Install the Android SDK core component,<br />
# Install one or several Android SDK Platform packages,<br />
# Install one of the IDEs compatible with the Android SDK.<br />
<br />
=== Android SDK core components ===<br />
<br />
{{Note|First, if you are running a 64-bit system, make sure the [[multilib]] repository is enabled in [[Pacman#Repositories|pacman.conf]]. Otherwise errors of the type: "error: target not found: lib32-zlib" will plague your installation attempt.}}<br />
<br />
Before developing Android applications, you need to install the Android SDK, which is made of 3 distinct packages, all installable from [[Arch User Repository|AUR]]:<br />
<br />
# {{AUR|android-sdk}}<br />
# {{AUR|android-sdk-platform-tools}}<br />
# {{AUR|android-sdk-build-tools}}<br />
<br />
Android-sdk will be installed on {{ic|/opt/android-sdk}}. This folder has root permissions, so keep in mind to run sdk manager as root, otherwise you will not be able to install/update/modify anything on /opt/android-sdk. However, if you intend to use it as a regular user, create an android sdk users group (or use any group name you want):<br />
# groupadd sdkusers<br />
<br />
Add your user into this group:<br />
# gpasswd -a <user> sdkusers<br />
<br />
Change folder's group.<br />
# chown -R :sdkusers /opt/android-sdk/<br />
<br />
Change permissions of the folder so the user that was just added to the group will be able to write in it:<br />
# chmod -R g+w /opt/android-sdk/<br />
<br />
{{Note|As an alternative to a global install with the [[AUR]] packages, the SDK can be installed to a user's home directory via [https://developer.android.com/sdk/index.html the upstream instructions].}}<br />
<br />
=== Android SDK platform API ===<br />
<br />
Install the desired Android SDK Platform package from the [[AUR]]:<br />
<br />
* {{aur|android-platform}} (latest)<br />
* {{aur|android-platform-21}}<br />
* {{aur|android-platform-20}}<br />
* {{aur|android-platform-19}}<br />
* {{aur|android-platform-18}}<br />
* {{aur|android-platform-17}}<br />
* {{aur|android-platform-16}}<br />
* {{aur|android-platform-15}}<br />
* {{aur|android-platform-14}}<br />
* {{aur|android-platform-13}}<br />
* {{aur|android-platform-12}}<br />
* {{aur|android-platform-11}}<br />
* {{aur|android-platform-10}}<br />
* {{aur|android-platform-9}}<br />
* {{aur|android-platform-8}}<br />
* {{aur|android-platform-7}}<br />
* {{aur|android-platform-6}}<br />
* {{aur|android-platform-5}}<br />
* {{aur|android-platform-4}}<br />
* {{aur|android-platform-3}}<br />
* {{aur|android-platform-2}}<br />
<br />
=== Development environment ===<br />
<br />
Android Studio is the new official Android development environment based on IntelliJ IDEA. Alternatively, you can use [[Eclipse]] with the official but deprecated ADT plugin, or [[Netbeans]] with the NBAndroid plugin. All are described below.<br />
<br />
==== Android Studio ====<br />
<br />
[http://developer.android.com/sdk/installing/studio.html Android Studio] is the new official Android development environment based on IntelliJ IDEA. Similar to Eclipse with the ADT Plugin, Android Studio provides integrated Android developer tools for development and debugging.<br />
<br />
You can download and install it with the {{AUR|android-studio}} package from the AUR. If you get an error about a missing SDK, refer to the section Getting Android SDK platform API above.<br />
<br />
{{Note|1=If you are using other tiling window manager than i3wm, you may need to apply one of the fixes mentioned in [https://code.google.com/p/android/issues/detail?id=57675 this] issue page.}}<br />
<br />
{{Note|1=Bad font rendering in Android Studio can be fixed by installing the [[Infinality#Installation_2|infinality-bundle]] and using infinality patched openJDK 7 ({{AUR|jdk7-openjdk-infinality}}) or openJDK 8 ({{AUR|jdk8-openjdk-infinality}}) from the AUR as mentioned in [https://youtrack.jetbrains.com/issue/IDEA-57233#comment=27-876236 this] issue page.}}<br />
<br />
==== Eclipse ====<br />
<br />
{{Note|Since 2014-12-08, the ADT plugin is officially considered deprecated and Android Studio is now the official IDE.}}<br />
<br />
Most stuff required for Android development in Eclipse is already packaged in AUR:<br />
<br />
Official plugin by Google &ndash; [http://developer.android.com/sdk/eclipse-adt.html Eclipse ADT]:<br />
# {{AUR|eclipse-android}}<br />
<br />
Dependencies:<br />
# {{AUR|eclipse-emf}}<br />
# {{AUR|eclipse-gef}}<br />
# {{AUR|eclipse-wtp}}<br />
<br />
{{Note|<br />
* if you get a message about unresolvable dependencies, install [[Java]] manually and try again.<br />
* as an alternative, you can install the ADT via eclipse's built in "add new software" command (see instructions on ADT site).<br />
* if you are in real trouble, it is also possible to download Android SDK and use the bundled Eclipse. This usually works without problems.<br />
* if you need to install extra SDK plugins not found in the AUR, you must change the file ownership of /opt/android-sdk first. You can do this with {{ic|# chgrp -R users /opt/android-sdk ; chmod -R 0775 /opt/android-sdk}} (see [[File Permissions]] for more details).<br />
}}<br />
<br />
Enter the path to the Android SDK Location in<br />
<br />
Windows -> Preferences -> Android<br />
<br />
{{Note|<br />
If the plugins do not show up in Eclipse after the AUR package has been upgraded, then eclipse probably has out-of-date caches. Running {{ic|sudo eclipse -clean}} once should clear them. If the problem persists, uninstall eclipse and all the plugins, delete {{ic|/usr/share/eclipse}}, and reinstall everything.<br />
}}<br />
<br />
==== Netbeans ====<br />
<br />
If you prefer using [[Netbeans]] as your IDE and want to develop Android applications, download the [http://www.nbandroid.org NBAndroid] by going to:<br />
<br />
Tools -> Plugins -> Settings<br />
<br />
Add the following URL: http://nbandroid.org/updates/updates.xml<br />
<br />
Then go to '''Available Plugins''' and install the '''Android''' and '''JUnit''' plugins. Once you have installed go to:<br />
<br />
Tools -> Options -> Miscellaneous -> Android<br />
<br />
and select the path where the SDK is installed (/opt/android-sdk by default). That is it, now you can create a new Android project and start developing using Netbeans.<br />
<br />
=== Connecting to a real device - Android Debug Bridge (ADB) ===<br />
<br />
{{Tip|For some devices, you may have to enable MTP on the device, before ADB will work.}}<br />
<br />
To get ADB to connect to a real device or phone under Arch, you must:<br />
<br />
* Install {{Pkg|android-tools}}.<br />
* Enable USB Debugging on your phone or device:<br />
** Jelly Bean (4.2) and newer: Go to {{ic|Settings --> About Phone}} tap “Build Number” until you get a popup that you have become a developer (about 10 times). Then go to {{ic|Settings --> Developer --> USB debugging}} and enable it.<br />
** Older versions: This is usually done from {{ic|Settings --> Applications --> Development --> USB debugging}}. Reboot the phone after checking this option to make sure USB debugging is enabled.<br />
* install {{Pkg|android-udev}} to connect the device to the proper {{ic|/dev/}} entries.<br />
* Add yourself to the ''adbusers'' group. ({{ic|gpasswd -a ''username'' adbusers}})<br />
<br />
If [[#Does it work?|ADB recognizes your device]] (it is visible and accessible in IDE), you are done. Otherwise see instructions below.<br />
<br />
==== Figure out device IDs ====<br />
<br />
Each Android device has a USB vendor/product ID. An example for HTC Evo is:<br />
<br />
vendor id: 0bb4<br />
product id: 0c8d<br />
<br />
Plug in your device and execute:<br />
<br />
$ lsusb<br />
<br />
It should come up something like this:<br />
<br />
Bus 002 Device 006: ID 0bb4:0c8d High Tech Computer Corp.<br />
<br />
==== Adding udev Rules ====<br />
<br />
Use the rules from [http://source.android.com/source/initializing.html#configuring-usb-access Android developer] or you can use the following template for your udev rules, just replace [VENDOR ID] and [PRODUCT ID] with yours. Copy these rules into {{ic|/etc/udev/rules.d/51-android.rules}}:<br />
<br />
{{hc|/etc/udev/rules.d/51-android.rules|2=<nowiki>SUBSYSTEM=="usb", ATTR{idVendor}=="[VENDOR ID]", MODE="0666"<br />
SUBSYSTEM=="usb",ATTR{idVendor}=="[VENDOR ID]",ATTR{idProduct}=="[PRODUCT ID]",SYMLINK+="android_adb"<br />
SUBSYSTEM=="usb",ATTR{idVendor}=="[VENDOR ID]",ATTR{idProduct}=="[PRODUCT ID]",SYMLINK+="android_fastboot"</nowiki>}}<br />
<br />
Then, to reload your new udev rules, execute:<br />
# udevadm control --reload-rules<br />
<br />
==== Configuring adb ====<br />
<br />
Instead of using udev rules, you may create/edit {{ic|~/.android/adb_usb.ini}} which contains a list of vendor IDs.<br />
<br />
$ cat ~/.android/adb_usb.ini <br />
0x27e8<br />
<br />
==== Does it work? ====<br />
<br />
After you have setup the udev rules, unplug your device and replug it.<br />
<br />
After running:<br />
<br />
$ adb devices<br />
<br />
you should see something like:<br />
<br />
List of devices attached <br />
HT07VHL00676 device<br />
<br />
You can now use adb to transfer files between the device and your computer. To transfer files to the device, use<br />
$ adb push ''<what-to-copy>'' ''<where-to-place>''<br />
<br />
To transfer files from the device, use<br />
$ adb pull ''<what-to-pull>'' ''<where-to-place>''<br />
<br />
If you do not have the '''adb''' program, it means you have installed neither [[#Android SDK platform API|platform tools]](usually available in {{Ic|/opt/android-sdk/platform-tools/}}) nor {{Pkg|android-tools}}(available in {{Ic|/usr/bin/}}).<br />
<br />
If you are getting an empty list (your device is not there), it may be because you have not enabled USB debugging on your device. You can do that by going to Settings => Applications => Development and enabling USB debugging. On Android 4.2 (Jelly Bean) the Development menu is hidden; to enable it go to Settings => About phone and tap Build number 7 times.<br />
<br />
If there are still problems such as ''adb'' displaying {{ic|???????? no permissions}} under devices, try restarting the adb server as root.<br />
# adb kill-server<br />
# adb start-server<br />
<br />
=== NVIDIA Tegra platform ===<br />
<br />
If you target your application at NVIDIA Tegra platform, you might also want to install tools, samples and documentation provided by NVIDIA. In [http://developer.nvidia.com/category/zone/mobile-development NVIDIA Developer Zone for Mobile] there are two tools: <br />
<br />
# The [http://developer.nvidia.com/tegra-resources Tegra Android Development Pack] provides tools (NVIDIA Debug Manager) related to [http://developer.android.com/sdk/eclipse-adt.html Eclipse ADT] and their documentation. <br />
# The [http://developer.nvidia.com/tegra-resources Tegra Toolkit] provides tools (mostly CPU and GPU optimization related), samples and documentation. <br />
<br />
Both are currently not available in the [[AUR]] anymore, because NVIDIA requires a registration/login for the download.<br />
<br />
== Building Android ==<br />
<br />
Please note that these instructions are based on the [http://source.android.com/source/building.html official AOSP build instructions]. Other Android-derived systems such as CyanogenMod will often require extra steps.<br />
<br />
=== OS bitness ===<br />
<br />
Android 2.2.x (Froyo) and below are the only versions of Android that will build on a 32-bit system. For 2.3.x (Gingerbread) and above, you will need a 64-bit installation. <br />
<br />
=== Required packages ===<br />
<br />
To build any version of Android, you need to install these packages:<br />
<br />
* 32-bit and 64-bit systems: {{Pkg|gcc}} {{Pkg|git}} {{Pkg|gnupg}} {{Pkg|flex}} {{Pkg|bison}} {{Pkg|gperf}} {{Pkg|sdl}} {{Pkg|wxgtk}} {{Pkg|squashfs-tools}} {{Pkg|curl}} {{Pkg|ncurses}} {{Pkg|zlib}} {{Pkg|schedtool}} {{Pkg|perl-switch}} {{Pkg|zip}} {{Pkg|unzip}} {{Pkg|libxslt}} {{Pkg|python2-virtualenv}} {{Pkg|bc}}<br />
<br />
* 64-bit systems only: {{Pkg|gcc-multilib}} {{Pkg|lib32-zlib}} {{Pkg|lib32-ncurses}} {{Pkg|lib32-readline}}<br />
<br />
=== Java Development Kit ===<br />
<br />
Android 5 (Lollipop) can be built with {{Pkg|jdk7-openjdk}}.<br />
<br />
Older versions [http://source.android.com/source/initializing.html require] a working '''Oracle JDK''' installed on your build system. It '''will not''' work with OpenJDK.<br />
*For Gingerbread through KitKat (2.3 - 4.4), Java 6 is required, which is available as {{AUR|jdk6}} from the AUR. See [[Java]] if you want to use it besides another (newer) JDK version.<br />
*For Cupcake through Froyo (1.5 - 2.2), Java 5 is required, which is no longer available for Arch Linux.<br />
<br />
=== Setting up the build environment ===<br />
<br />
Download the {{ic|repo}} utility per [https://source.android.com/source/downloading.html Android Downloading the Source guide].<br />
<br />
$ mkdir ~/bin<br />
$ export PATH=~/bin:$PATH<br />
$ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo<br />
$ chmod a+x ~/bin/repo<br />
<br />
Create a directory to build.<br />
<br />
$ mkdir ~/android<br />
$ cd ~/android<br />
<br />
You will need to change the default Python from version 3 to version 2:<br />
<br />
$ virtualenv2 venv # Creates a directory, venv/, containing the Virtualenv<br />
<br />
{{Note|During build you may receive error pertaining to missing python modules. A quick and dirty fix is to symlink /usr/lib/python2.7/* to ~/android/venv/python2.7/ (Change ~/android to reflect your build directory if different than above).<br />
Example:<br />
$ ln -s /usr/lib/python2.7/* /Data/Android_Build/venv/lib/python2.7/<br />
}}<br />
Activate the Virtualenv, which will update $PATH to point at Python 2.<br />
<br />
{{Note|this activation is only active for the current terminal session.<br />
}}<br />
<br />
$ source venv/bin/activate<br />
<br />
=== Downloading the source code ===<br />
<br />
This will clone the repositories. You '''only''' need to do this the first time you build Android, or if you want to switch branches.<br />
<br />
* The {{ic|repo}} has a {{ic|-j}} switch that operates similarly to the one used with {{ic|make}}. Since it controls the number of simultaneous downloads, you should adjust the value depending on downstream network bandwidth.<br />
<br />
* You will need to specify a '''branch''' (release of Android) to check out with the {{ic|-b}} switch. If you leave the switch out, you will get the so-called '''master branch'''.<br />
<br />
$ repo init -u https://android.googlesource.com/platform/manifest -b master<br />
$ repo sync -j4<br />
<br />
{{Note|To further decrease sync times, you can utilize the -c switch with the repo command as such:<br />
$ repo sync -j8 -c<br />
The {{ic|-c}} switch will only sync the branch which is specified in the manifest, which in turn is determined by the branch specified with the {{ic|-b}} switch, or the default branch set by the repository maintainer.<br />
}}<br />
<br />
Wait a long time. Just the uncompiled source code, along with the {{ic|.repo}} and {{ic|.git}} directories that are used to keep track of it, are well over 10 GB.<br />
<br />
{{Note|If you want to update your local copy of the Android source, at a later time, simply enter the build directory, load the Virtualenv, and re-sync:<br />
$ repo sync<br />
}}<br />
<br />
=== Building the code ===<br />
<br />
This should do what you need for AOSP:<br />
<br />
$ source build/envsetup.sh<br />
$ lunch full-eng<br />
$ make -j4<br />
<br />
If you run '''lunch''' without arguments, it will ask what build you want to create. Use -j with a number between one and two times number of cores/threads.<br />
<br />
The build takes a very long time.<br />
<br />
{{Note|Make sure you have enough RAM.<br />
Android will use the /tmp directory heavily. By default the size of the partition the /tmp folder is mounted on is half the size of your RAM. If it fills up, the build will fail. 4GB of RAM or more is recommended.<br />
* Alternatively, you can get rid of the tmpfs from [[Fstab|fstab]] all together. <br />
}}<br />
<br />
{{Note|From the [https://source.android.com/source/building-running.html#build-the-code Android Building and Running guide]:<br />
<br />
"GNU make can handle parallel tasks with a -jN argument, and it's common to use a number of tasks N that's between 1 and 2 times the number of hardware threads on the computer being used for the build. E.g. on a dual-E5520 machine (2 CPUs, 4 cores per CPU, 2 threads per core), the fastest builds are made with commands between make -j16 and make -j32."<br />
<br />
}}<br />
=== Testing the build ===<br />
<br />
When finished, run/test the final image(s).<br />
<br />
$ emulator<br />
<br />
=== Creating a Flashable Image ===<br />
To create an image that can be flashed it is necessary to:<br />
<br />
make -j8 updatepackage<br />
<br />
This will create a zip image under '''out/target/product/hammerhead''' (hammerhead being the device name) that can be flashed.<br />
<br />
== Alternative connection methods ==<br />
<br />
=== AirDroid ===<br />
<br />
AirDroid is an Android app to access files from your web browser.<br />
<br />
=== FTP ===<br />
<br />
You run a FTP server on Arch and connect to it from your phone, or the other way around: run a FTP server on your phone and connect to it from Arch.<br />
<br />
See [[List of applications/Internet#FTP]]. There are a lot of FTP clients/servers available for Android.<br />
<br />
=== SSH Server ===<br />
<br />
There are many SSH servers available for Android, it allows you to transfer files using {{ic|scp}} command. See also [[SSH]].<br />
<br />
=== Samba ===<br />
<br />
See [[Samba]].<br />
<br />
== Tips & Tricks ==<br />
<br />
=== During Debugging "Source not found" ===<br />
<br />
Most probably the debugger wants to step into the Java code. As the source code of Android does not come with the Android SDK, this leads to an error. The best solution is to use step filters to not jump into the Java source code. Step filters are not activated by default. To activate them: <br />
Window -> Preferences -> Java -> Debug -> Step Filtering<br />
Consider to select them all. If appropriate you can add the android.* package. See the forum post for more information: http://www.eclipsezone.com/eclipse/forums/t83338.rhtml<br />
<br />
=== Linux distribution on the sdcard ===<br />
<br />
You can install Debian like in this [http://forum.xda-developers.com/showthread.php?t=631389 thread]. Excellent guide to installing Arch in chroot (in parallel with Android) can be found on [http://archlinuxarm.org/forum/viewtopic.php?f=27&t=1361&start=40 archlinuxarm.org forum].<br />
<br />
== Troubleshooting ==<br />
<br />
=== aapt: No such file or directory ===<br />
<br />
The build tools include 32-bit binaries. For this reason they require 32-bit libraries. If you happened to install the SDK manually, you will additionally need to install<br />
'''multilib/lib32-libstdc++5''' and '''multilib/lib32-zlib'''.<br />
<br />
=== ValueError: unsupported pickle protocol ===<br />
<br />
One fix is to issue:<br />
<br />
rm ~/.repopickle_.gitconfig<br />
<br />
If that does not work, then try this:<br />
<br />
rm `find /path/to/android-root -name .repopickle_config`</div>Moviurohttps://wiki.archlinux.org/index.php?title=Talk:Android&diff=363283Talk:Android2015-03-01T13:44:43Z<p>Moviuro: /* Android SDK core components */</p>
<hr />
<div>I'll leave this here until I get enough time to put the changes in the wiki page: http://forum.xda-developers.com/showthread.php?t=2259929<br />
[[User:GermainZ|GermainZ]] ([[User talk:GermainZ|talk]]) 18:45, 4 May 2013 (UTC)<br />
<br />
== Eclipse ==<br />
<br />
I found installing the Android SDK within Eclipse is much more pleasant,<br />
especially when your developing alone. No need for AUR and chmod orgies.<br />
<br />
Open up Eclipse, go to Help - Install new Software - Add...<br />
<br />
enter <br />
https://dl-ssl.google.com/android/eclipse/<br />
<br />
and choose "Developer Tools"<br />
<br />
In my case everything was installed to<br />
<br />
~/Development/android-sdks<br />
(of course the installer lets you choose any directory that suits you best)<br />
<br />
After that, close eclipse,<br />
<br />
cd ~/Development/android-sdks/tools and fire up the Android SDK Manager ./android sdk<br />
<br />
to get additional libs and the latest updates (don't miss this step)<br />
<br />
You can now create a new Android project in Eclipse and everything works fine!<br />
<br />
[[User:Goodboy|Goodboy]] ([[User talk:Goodboy|talk]]) 14:46, 6 July 2013 (UTC)<br />
<br />
== Java/OpenJDK ==<br />
<br />
I always build with no problems Android using OpenJDK. I think it was OpenJDK 7, but I'm going to build Android again so I'll see which one works best.<br />
Anyway there's no need to use Oracle Java.<br />
<br />
As of November 3/4, 2014 with the release of Android 5.0, Android will no longer build with Oracle Java. (I remember reading this somewhere on the internet and this was also my experience when trying to build 5.0 with Oracle Java. After switching to OpenJDK 7 there were no build issues related to java. [[User:Orkeren|Orkeren]] ([[User talk:Orkeren|talk]]) 21:26, 4 November 2014 (UTC)<br />
<br />
== Android SDK core components ==<br />
<br />
Find the line where it says:<br />
# chown -R :sdkusers /opt/android-sdk/<br />
<br />
And should be like this:<br />
# chown -R <user>:sdkusers /opt/android-sdk/<br />
You must change it from root user to your regular user, otherwise it just won't let you edit anything at {{ic|/opt/android-sdk/}}. Who da heck changed it? I've already tested it in the past.<br />
<br />
* I did, because it makes no sense to put a particular user in charge (and, it '''is''' the point of groups). I also added that you should use {{ic|chmod -R g+w}} afterwards to have it working. [[User:Moviuro|Moviuro]] ([[User talk:Moviuro|talk]]) 13:44, 1 March 2015 (UTC)</div>Moviurohttps://wiki.archlinux.org/index.php?title=Systemd-boot&diff=361777Systemd-boot2015-02-19T08:24:18Z<p>Moviuro: /* Legacy boot */ minor edits and reformulation</p>
<hr />
<div>{{DISPLAYTITLE:gummiboot}}<br />
[[Category:Boot loaders]]<br />
[[de:Gummiboot]]<br />
[[es:Gummiboot]]<br />
[[ja:Gummiboot]]<br />
[[ru:Gummiboot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related articles end}}<br />
<br />
From [http://freedesktop.org/wiki/Software/gummiboot/ gummiboot homepage]:<br />
:''gummiboot is a simple UEFI boot manager which executes configured EFI images. The default entry is selected by a configured pattern (glob) or an on-screen menu''.<br />
<br />
It is simple to configure, but can only start EFI executables, the Linux kernel [[EFISTUB]], UEFI Shell, grub.efi, and such.<br />
<br />
{{Warning|gummiboot simply provides a boot menu for EFISTUB kernels. In case you have issues booting EFISTUB kernels like in {{Bug|33745}}, you should use a boot loader which does not use EFISTUB, like [[GRUB]], [[Syslinux]] or [[Boot loaders#ELILO|ELILO]].}}<br />
<br />
{{Note|In the entire article {{ic|$esp}} denotes the mountpoint of the [[UEFI#EFI System Partition|EFI System Partition]] aka ESP.}}<br />
<br />
== Installation ==<br />
<br />
=== EFI boot ===<br />
First, make sure you are booted in UEFI mode, [[UEFI#Requirements for UEFI Variables support to work properly|your EFI variables are accessible]], your EFI System Partition is properly mounted and your kernel and initramfs are copied onto that ESP as gummiboot cannot load EFI binaries from other partitions. It is therefore strongly recommended to mount your ESP to {{ic|/boot}} if you use gummiboot.<br />
<br />
Then, [[install]] the package {{Pkg|gummiboot}} from the [[official repositories]].<br />
<br />
Finally, type the following command to copy the gummiboot binary to your EFI System Partition and add gummiboot itself as the default EFI application (default boot entry) loaded by the EFI Boot Manager. If you are not booted in UEFI mode and your EFI variables are not accessible, creating the boot entry will fail. You should however still be able to boot gummiboot as it copies the binary to the default EFI binary location on your ESP ({{ic|$esp/EFI/boot/bootx64.efi}} on x64 systems) unless a non-gummiboot EFI application is already present as the same filename.<br />
<br />
# gummiboot --path=''$esp'' install<br />
<br />
=== Legacy boot ===<br />
{{Note|This is not the recommended process}}<br />
You can also successfully install gummiboot if booted with a legacy OS. However, this requires that you later on tell your firmware to launch gummiboot's EFI file on boot:<br />
* you either have a working EFI shell somewhere;<br />
* or your firmware interface provides you with a way of properly setting the EFI file that will be loaded at boot time.<br />
{{Note|E.g. on Dell's Latitude series, the firmware interface provides everything you need to setup EFI boot, and the EFI Shell won't be able to write to the computer's ROM.}}<br />
If you can do so, the installation is easier: [[install]] {{Pkg|gummiboot}} from the [[official repositories]], go into your EFI shell or your firmware configuration interface and change your machine's default EFI file to {{ic|/<EFI boot partition>/efi/gummiboot/gummibootx64.efi}}.<br />
<br />
=== Updating ===<br />
<br />
gummiboot assumes that your EFI System Partition is mounted on {{ic|/boot}} in which case, each time a new gummiboot version is installed, the command {{ic|1=gummiboot --path=''$esp'' update}} will be called automatically by the {{ic|post_install}} method of the install script. If your ESP is not mounted on {{ic|/boot}}, you will have to call manually that command.<br />
<br />
== Configuration ==<br />
<br />
=== Basic configuration ===<br />
<br />
The basic configuration is kept in {{ic|$esp/loader/loader.conf}}, with just two possible configuration options:<br />
<br />
* {{ic|default}} – default entry to select (without the {{ic|.conf}} suffix); can be a wildcard like {{ic|arch-*}}<br />
<br />
* {{ic|timeout}} – menu timeout in seconds. If this is not set, the menu will only be shown when you hold the space key while booting.<br />
<br />
Example:<br />
<br />
{{hc|$esp/loader/loader.conf|<br />
default arch<br />
timeout 4<br />
}}<br />
<br />
Note that both options can be changed in the boot menu itself, which will store them as EFI variables.<br />
<br />
{{Note|If no timeout is configured, which is the default setting, and no key pressed during bootup, the default entry is executed right away.}}<br />
<br />
=== Adding boot entries ===<br />
{{Note|gummiboot will automatically check for "'''Windows Boot Manager'''" ({{ic|\EFI\Microsoft\Boot\Bootmgfw.efi}}), "'''EFI Shell'''" ({{ic|\shellx64.efi}}) and "'''EFI Default Loader'''" ({{ic|\EFI\Boot\bootx64.efi}}). Where detected, entries will also automatically be generated for them as well. However, it does not auto-detect other EFI applications (unlike [[rEFInd]]), so for booting the kernel, manual configuration entries must be created.}}<br />
<br />
{{Tip|You can find the PARTUUID for your Root partition with the command {{ic|1=blkid -s PARTUUID -o value /dev/sdxY}}, where 'x' is the device letter and 'Y' is the partition number. This is required only for your Root partition, not $esp.}}<br />
<br />
gummiboot searches for boot menu items in {{ic|$esp/loader/entries/*.conf}} – each file found must contain exactly one boot entry. The possible options are:<br />
<br />
* {{ic|title}} – operating system name. '''Required.'''<br />
<br />
* {{ic|version}} – kernel version, shown only when multiple entries with same title exist. Optional.<br />
<br />
* {{ic|machine-id}} – machine identifier from {{ic|/etc/machine-id}}, shown only when multiple entries with same title and version exist. Optional.<br />
<br />
* {{ic|efi}} – EFI program to start, relative to your ESP ({{ic|$esp}}); e.g. {{ic|/vmlinuz-linux}}. Either this or {{ic|linux}} (see below) is '''required.'''<br />
<br />
* {{ic|options}} – command line options to pass to the EFI program. Optional, but you will need at least {{ic|1=initrd=''efipath''}} and {{ic|1=root=''dev''}} if booting Linux.<br />
<br />
For Linux, you can specify {{ic|linux ''path-to-vmlinuz''}} and {{ic|initrd ''path-to-initramfs''}}; this will be automatically translated to {{ic|efi ''path''}} and {{ic|1=options initrd=''path''}} – this syntax is only supported for convenience and has no differences in function. <br />
<br />
==== Standard root installations ====<br />
<br />
Here is an example entry for a root partition without LVM or LUKS:<br />
<br />
{{hc|$esp/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw<br />
}}<br />
<br />
Please note in the example above that PARTUUID/PARTLABEL identifies a GPT partition, and differs from UUID/LABEL, which identifies a filesystem. Using the PARTUUID/PARTLABEL is advantageous because it is invariant (i.e. unchanging) if you reformat the partition with another filesystem, or if the /dev/sd* mapping changed for some reason. It is also useful if you do not have a filesystem on the partition (or use LUKS, which does not support LABELs).<br />
<br />
==== LVM root installations ====<br />
<br />
Here is an example for a root partition using [[Lvm|Logical Volume Management]]:<br />
<br />
{{hc|$esp/loader/entries/arch-lvm.conf|2=<br />
title Arch Linux (LVM)<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=/dev/mapper/<VolumeGroup-LogicalVolume> rw<br />
}}<br />
<br />
Replace {{ic|<VolumeGroup-LogicalVolume>}} with the actual VG and LV names (e.g. {{ic|1=root=/dev/mapper/volgroup00-lvolroot}}). Alternatively, it is also possible to use a UUID instead:<br />
....<br />
options root=UUID=<UUID identifier> rw<br />
<br />
Note that {{ic|1=root='''UUID'''=}} is used instead of {{ic|1=root='''PARTUUID'''=}}, which is used for Root partitions without LVM or LUKS.<br />
<br />
==== Encrypted Root Installations ====<br />
<br />
Here is an example configuration file for an encrypted root partition ([[Dm-crypt|DM-Crypt / LUKS]]):<br />
<br />
{{hc|$esp/loader/entries/arch-encrypted.conf|2=<br />
title Arch Linux Encrypted<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options cryptdevice=UUID=<UUID>:<mapped-name> root=UUID=<luks-UUID> quiet ro<br />
}}<br />
<br />
UUID is used in this example; PARTUUID should be able to replace the UUID, if so desired. Note that {{ic|<luks-UUID>}} denotes the UUID of the actual decrypted root filesystem (the one under {{Ic|/dev/mapper/<mapped-name>}}) and not the UUID of the device. See [[Dm-crypt/System configuration#Boot loader]].<br />
<br />
You can also add other EFI programs such as {{ic|\EFI\arch\grub.efi}}.<br />
<br />
=== Add security ===<br />
<br />
You have to note that the kernel command line parameters can be edited from the gummiboot's boot manager menu (see [[#Keys inside the boot menu]]) by pressing {{ic|e}}. This is a major security flaw since if you redefine the {{ic|1=init=}} kernel argument with {{ic|1=init=/bin/bash}} for example, this will boot your machine directly as root without any password, bypassing easily the root password that has been defined! Since gummiboot does not currently have a password feature and has no ability to prevent kernel parameters changes, you need to make sure to define a password at hardware level (UEFI/BIOS) which prevents the computer to boot if the right password has not been entered.<br />
<br />
Since security is made of several levels and physical access already breaks any security systems, maybe encrypting your disk with [[dm-crypt]] would come in handy especially if your machine is a laptop. But this is another concern not related to gummiboot.<br />
<br />
=== Support hibernation ===<br />
<br />
Please refer to that article [[Suspend and hibernate]], especially the [[Suspend and hibernate#Example for gummiboot|Example for gummiboot]].<br />
<br />
== Keys inside the boot menu ==<br />
<br />
The following keys are used inside the menu:<br />
* {{ic|Up/Down}} - select entry<br />
* {{ic|Enter}} - boot the selected entry<br />
* {{ic|d}} - select the default entry to boot (stored in a non-volatile EFI variable)<br />
* {{ic|-/T}} - decrease the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|+/t}} - increase the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|e}} - edit the kernel command line<br />
* {{ic|v}} - show the gummiboot and UEFI version<br />
* {{ic|Q}} - quit<br />
* {{ic|P}} - print the current configuration<br />
* {{ic|h/?}} - help<br />
<br />
These hotkeys will, when pressed inside the menu or during bootup, directly boot<br />
a specific entry:<br />
<br />
* {{ic|l}} - Linux<br />
* {{ic|w}} - Windows<br />
* {{ic|a}} - OS X<br />
* {{ic|s}} - EFI Shell<br />
* {{ic|1-9}} - number of entry<br />
<br />
== Troubleshooting ==<br />
<br />
=== Manual entry using efibootmgr ===<br />
<br />
If {{ic|gummiboot install}} command failed, you can create a EFI boot entry manually using {{ic|efibootmgr}} utility:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/gummiboot/gummibootx64.efi -L "Gummiboot"<br />
<br />
where {{ic|/dev/sdXY}} is the EFISYS partition.<br />
<br />
=== Menu does not appear after Windows upgrade ===<br />
<br />
For example, if you upgraded from Windows 8 to Windows 8.1, and you no longer see a boot menu after the upgrade (i.e., Windows boots immediately):<br />
* Make sure Secure Boot (UEFI setting) and Fast Startup (Windows power option setting) are both disabled.<br />
* Make sure your UEFI prefers Linux Boot Manager over Windows Boot Manager (UEFI setting like Hard Drive Disk Priority).<br />
<br />
== See also ==<br />
<br />
* http://freedesktop.org/wiki/Software/gummiboot/</div>Moviurohttps://wiki.archlinux.org/index.php?title=Systemd-boot&diff=361346Systemd-boot2015-02-15T21:57:54Z<p>Moviuro: /* Encrypted Root Installations */ add minor exhaustive explanations</p>
<hr />
<div>{{DISPLAYTITLE:gummiboot}}<br />
[[Category:Boot loaders]]<br />
[[de:Gummiboot]]<br />
[[es:Gummiboot]]<br />
[[ja:Gummiboot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related articles end}}<br />
<br />
From [http://freedesktop.org/wiki/Software/gummiboot/ gummiboot homepage]:<br />
:''gummiboot is a simple UEFI boot manager which executes configured EFI images. The default entry is selected by a configured pattern (glob) or an on-screen menu''.<br />
<br />
It is simple to configure, but can only start EFI executables, the Linux kernel [[EFISTUB]], UEFI Shell, grub.efi, and such.<br />
<br />
{{Warning|gummiboot simply provides a boot menu for EFISTUB kernels. In case you have issues booting EFISTUB kernels like in {{Bug|33745}}, you should use a boot loader which does not use EFISTUB, like [[GRUB]], [[Syslinux]] or [[Bootloaders#ELILO|ELILO]].}}<br />
<br />
{{Note|In the entire article {{ic|$esp}} denotes the mountpoint of the [[UEFI#EFI System Partition|EFI System Partition]] aka ESP.}}<br />
<br />
== Installation ==<br />
<br />
=== EFI boot ===<br />
First, make sure you are booted in UEFI mode, [[UEFI#Requirements for UEFI Variables support to work properly|your EFI variables are accessible]], your EFI System Partition is properly mounted and your kernel and initramfs are copied onto that ESP as gummiboot cannot load EFI binaries from other partitions. It is therefore strongly recommended to mount your ESP to {{ic|/boot}} if you use gummiboot.<br />
<br />
Then, [[install]] the package {{Pkg|gummiboot}} from the [[official repositories]].<br />
<br />
Finally, type the following command to copy the gummiboot binary to your EFI System Partition and add gummiboot itself as the default EFI application (default boot entry) loaded by the EFI Boot Manager. If you are not booted in UEFI mode and your EFI variables are not accessible, creating the boot entry will fail. You should however still be able to boot gummiboot as it copies the binary to the default EFI binary location on your ESP ({{ic|$esp/EFI/boot/bootx64.efi}} on x64 systems) unless a non-gummiboot EFI application is already present as the same filename.<br />
<br />
# gummiboot --path=''$esp'' install<br />
<br />
=== Legacy boot ===<br />
{{Note|This is not the recommended process}}<br />
You can also successfully install gummiboot if booted with a legacy OS. However, this requires that you later on tell your firmware to launch gummiboot's EFI file on boot:<br />
* you have a working EFI shell somewhere;<br />
* your firmware interface provides you with a way of properly setting the EFI file that will be loaded at boot time. {{Note|This is for example possible on Dell's Latitude series, as the EFI Shell won't be able to write to the computer's ROM.}}<br />
If you can do so, the installation is easier: [[install]] {{Pkg|gummiboot}} from the [[official repositories]], go into your EFI shell or your firmware configuration interface and change your machine's defualt EFI file to {{ic|/<EFI boot partition>/efi/gummiboot/gummibootx64.efi}}.<br />
<br />
=== Updating ===<br />
<br />
gummiboot assumes that your EFI System Partition is mounted on {{ic|/boot}} in which case, each time a new gummiboot version is installed, the command {{ic|1=gummiboot --path=''$esp'' update}} will be called automatically by the {{ic|post_install}} method of the install script. If your ESP is not mounted on {{ic|/boot}}, you will have to call manually that command.<br />
<br />
== Configuration ==<br />
<br />
=== Basic Configuration ===<br />
<br />
The basic configuration is kept in {{ic|$esp/loader/loader.conf}}, with just two possible configuration options:<br />
<br />
* {{ic|default}} – default entry to select (without the {{ic|.conf}} suffix); can be a wildcard like {{ic|arch-*}}<br />
<br />
* {{ic|timeout}} – menu timeout in seconds. If this is not set, the menu will only be shown when you hold the space key while booting.<br />
<br />
Example:<br />
<br />
{{hc|$esp/loader/loader.conf|<br />
default arch<br />
timeout 4<br />
}}<br />
<br />
Note that both options can be changed in the boot menu itself, which will store them as EFI variables.<br />
<br />
{{Note|If no timeout is configured, which is the default setting, and no key pressed during bootup, the default entry is executed right away.}}<br />
<br />
=== Adding boot entries ===<br />
{{Note|gummiboot will automatically check for "'''Windows Boot Manager'''" ({{ic|\EFI\Microsoft\Boot\Bootmgfw.efi}}), "'''EFI Shell'''" ({{ic|\shellx64.efi}}) and "'''EFI Default Loader'''" ({{ic|\EFI\Boot\bootx64.efi}}). Where detected, entries will also automatically be generated for them as well. However, it does not auto-detect other EFI applications (unlike [[rEFInd]]), so for booting the kernel, manual configuration entries must be created.}}<br />
<br />
{{Tip|You can find the PARTUUID for your Root partition with the command {{ic|1=blkid -s PARTUUID -o value /dev/sdxY}}, where 'x' is the device letter and 'Y' is the partition number. This is required only for your Root partition, not $esp.}}<br />
<br />
gummiboot searches for boot menu items in {{ic|$esp/loader/entries/*.conf}} – each file found must contain exactly one boot entry. The possible options are:<br />
<br />
* {{ic|title}} – operating system name. '''Required.'''<br />
<br />
* {{ic|version}} – kernel version, shown only when multiple entries with same title exist. Optional.<br />
<br />
* {{ic|machine-id}} – machine identifier from {{ic|/etc/machine-id}}, shown only when multiple entries with same title and version exist. Optional.<br />
<br />
* {{ic|efi}} – EFI program to start, relative to your ESP ({{ic|$esp}}); e.g. {{ic|/vmlinuz-linux}}. Either this or {{ic|linux}} (see below) is '''required.'''<br />
<br />
* {{ic|options}} – Command-line options to pass to the EFI program. Optional, but you will need at least {{ic|1=initrd=''efipath''}} and {{ic|1=root=''dev''}} if booting Linux.<br />
<br />
For Linux, you can specify {{ic|linux ''path-to-vmlinuz''}} and {{ic|initrd ''path-to-initramfs''}}; this will be automatically translated to {{ic|efi ''path''}} and {{ic|1=options initrd=''path''}} – this syntax is only supported for convenience and has no differences in function. <br />
<br />
==== Standard Root Installations ====<br />
<br />
Here is an example entry for a root partition without LVM or LUKS:<br />
<br />
{{hc|$esp/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw<br />
}}<br />
<br />
Please note in the example above that PARTUUID/PARTLABEL identifies a GPT partition, and differs from UUID/LABEL, which identifies a filesystem. Using the PARTUUID/PARTLABEL is advantageous because it is invariant (i.e. unchanging) if you reformat the partition with another filesystem, or if the /dev/sd* mapping changed for some reason. It is also useful if you do not have a filesystem on the partition (or use LUKS, which does not support LABELs).<br />
<br />
==== LVM Root Installations ====<br />
<br />
Here is an example for a root partition using [[Lvm| Logical Volume Management]]:<br />
<br />
{{hc|$esp/loader/entries/arch-lvm.conf|2=<br />
title Arch Linux (LVM)<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=/dev/mapper/<VolumeGroup-LogicalVolume> rw<br />
}}<br />
<br />
Replace {{ic|<VolumeGroup-LogicalVolume>}} with the actual VG and LV names (e.g. {{ic|1=root=/dev/mapper/volgroup00-lvolroot}}). Alternatively, it is also possible to use a UUID instead:<br />
....<br />
options root=UUID=<UUID identifier> rw<br />
<br />
Note that {{ic|1=root='''UUID'''=}} is used instead of {{ic|1=root='''PARTUUID'''=}}, which is used for Root partitions without LVM or LUKS.<br />
<br />
==== Encrypted Root Installations ====<br />
<br />
Here is an example configuration file for an encrypted root partition ([[Dm-crypt|DM-Crypt / LUKS]]):<br />
<br />
{{hc|$esp/loader/entries/arch-encrypted.conf|2=<br />
title Arch Linux Encrypted<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options cryptdevice=UUID=<UUID>:<mapped-name> root=UUID=<luks-UUID> quiet ro<br />
}}<br />
<br />
UUID is used in this example; PARTUUID should be able to replace the UUID, if so desired. Note that {{ic|<luks-UUID>}} denotes the UUID of the actual decrypted root filesystem (the one under {{Ic|/dev/mapper/<mapped-name>}}) and not the UUID of the device. See [[Dm-crypt/System configuration#Boot loader]].<br />
<br />
You can also add other EFI programs such as {{ic|\EFI\arch\grub.efi}}.<br />
<br />
=== Add security ===<br />
<br />
You have to note that the kernel command line parameters can be edited from the gummiboot's boot manager menu (see [[#Keys]]) by pressing {{ic|e}}. This is a major security flaw since if you redefine the {{ic|1=init=}} kernel argument with {{ic|1=init=/bin/bash}} for example, this will boot your machine directly as root without any password, bypassing easily the root password that has been defined! Since gummiboot does not currently have a password feature and has no ability to prevent kernel parameters changes, you need to make sure to define a password at hardware level (UEFI/BIOS) which prevents the computer to boot if the right password has not been entered.<br />
<br />
Since security is made of several levels and physical access already breaks any security systems, maybe encrypting your disk with [[dm-crypt]] would come in handy especially if your machine is a laptop. But this is another concern not related to gummiboot.<br />
<br />
=== Support hibernation ===<br />
<br />
Please refer to that article [[Suspend and hibernate]], especially the [[Suspend and hibernate#Example for gummiboot|Example for gummiboot]].<br />
<br />
== Inside the boot menu ==<br />
<br />
=== Keys ===<br />
<br />
The following keys are used inside the menu:<br />
* {{ic|Up/Down}} - select entry<br />
* {{ic|Enter}} - boot the selected entry<br />
* {{ic|d}} - select the default entry to boot (stored in a non-volatile EFI variable)<br />
* {{ic|-/T}} - decrease the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|+/t}} - increase the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|e}} - edit the kernel command line<br />
* {{ic|v}} - show the gummiboot and UEFI version<br />
* {{ic|Q}} - quit<br />
* {{ic|P}} - print the current configuration<br />
* {{ic|h/?}} - help<br />
<br />
These hotkeys will, when pressed inside the menu or during bootup, directly boot<br />
a specific entry:<br />
<br />
* {{ic|l}} - Linux<br />
* {{ic|w}} - Windows<br />
* {{ic|a}} - OS X<br />
* {{ic|s}} - EFI Shell<br />
* {{ic|1-9}} - number of entry<br />
<br />
== Troubleshooting ==<br />
<br />
=== Manual entry using efibootmgr ===<br />
<br />
If {{ic|gummiboot install}} command failed, you can create a EFI boot entry manually using {{ic|efibootmgr}} utility:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/gummiboot/gummibootx64.efi -L "Gummiboot"<br />
<br />
where {{ic|/dev/sdXY}} is the EFISYS partition.<br />
<br />
=== Menu does not appear after Windows upgrade ===<br />
<br />
For example, if you upgraded from Windows 8 to Windows 8.1, and you no longer see a boot menu after the upgrade (i.e., Windows boots immediately):<br />
* Make sure Secure Boot (BIOS setting) and Fast Startup (Windows power option setting) are both disabled.<br />
* Make sure your BIOS prefers Linux Boot Manager over Windows Boot Manager (depending on your BIOS, this might appear under a BIOS setting like Hard Disk Drive Priority).<br />
<br />
== References ==<br />
<br />
* http://freedesktop.org/wiki/Software/gummiboot/</div>Moviurohttps://wiki.archlinux.org/index.php?title=Systemd-boot&diff=360470Systemd-boot2015-02-12T15:01:05Z<p>Moviuro: /* Legacy boot */ Reformulation of the note about Dell Latitudes</p>
<hr />
<div>{{DISPLAYTITLE:gummiboot}}<br />
[[Category:Boot loaders]]<br />
[[de:Gummiboot]]<br />
[[es:Gummiboot]]<br />
[[ja:Gummiboot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related articles end}}<br />
<br />
From [http://freedesktop.org/wiki/Software/gummiboot/ gummiboot homepage]:<br />
:''gummiboot is a simple UEFI boot manager which executes configured EFI images. The default entry is selected by a configured pattern (glob) or an on-screen menu''.<br />
<br />
It is simple to configure, but can only start EFI executables, the Linux kernel [[EFISTUB]], UEFI Shell, grub.efi, and such.<br />
<br />
{{Warning|gummiboot simply provides a boot menu for EFISTUB kernels. In case you have issues booting EFISTUB kernels like in {{Bug|33745}}, you should use a boot loader which does not use EFISTUB, like [[GRUB]], [[Syslinux]] or [[Bootloaders#ELILO|ELILO]].}}<br />
<br />
{{Note|In the entire article {{ic|$esp}} denotes the mountpoint of the [[UEFI#EFI System Partition|EFI System Partition]] aka ESP.}}<br />
<br />
== Installation ==<br />
<br />
=== EFI boot ===<br />
First, make sure you are booted in UEFI mode, [[UEFI#Requirements for UEFI Variables support to work properly|your EFI variables are accessible]], your EFI System Partition is properly mounted and your kernel and initramfs are copied onto that ESP as gummiboot cannot load EFI binaries from other partitions. It is therefore strongly recommended to mount your ESP to {{ic|/boot}} if you use gummiboot.<br />
<br />
Then, [[install]] the package {{Pkg|gummiboot}} from the [[official repositories]].<br />
<br />
Finally, type the following command to copy the gummiboot binary to your EFI System Partition and add gummiboot itself as the default EFI application (default boot entry) loaded by the EFI Boot Manager. If you are not booted in UEFI mode and your EFI variables are not accessible, creating the boot entry will fail. You should however still be able to boot gummiboot as it copies the binary to the default EFI binary location on your ESP ({{ic|$esp/EFI/boot/bootx64.efi}} on x64 systems) unless a non-gummiboot EFI application is already present as the same filename.<br />
<br />
# gummiboot --path=''$esp'' install<br />
<br />
=== Legacy boot ===<br />
{{Note|This is not the recommended process}}<br />
You can also successfully install gummiboot if booted with a legacy OS. However, this requires that you later on tell your firmware to launch gummiboot's EFI file on boot:<br />
* you have a working EFI shell somewhere;<br />
* your firmware interface provides you with a way of properly setting the EFI file that will be loaded at boot time. {{Note|This is for example possible on Dell's Latitude series, as the EFI Shell won't be able to write to the computer's ROM.}}<br />
If you can do so, the installation is easier: [[install]] {{Pkg|gummiboot}} from the [[official repositories]], go into your EFI shell or your firmware configuration interface and change your machine's defualt EFI file to {{ic|/<EFI boot partition>/efi/gummiboot/gummibootx64.efi}}.<br />
<br />
=== Updating ===<br />
<br />
gummiboot assumes that your EFI System Partition is mounted on {{ic|/boot}} in which case, each time a new gummiboot version is installed, the command {{ic|1=gummiboot --path=''$esp'' update}} will be called automatically by the {{ic|post_install}} method of the install script. If your ESP is not mounted on {{ic|/boot}}, you will have to call manually that command.<br />
<br />
== Configuration ==<br />
<br />
=== Basic Configuration ===<br />
<br />
The basic configuration is kept in {{ic|$esp/loader/loader.conf}}, with just two possible configuration options:<br />
<br />
* {{ic|default}} – default entry to select (without the {{ic|.conf}} suffix); can be a wildcard like {{ic|arch-*}}<br />
<br />
* {{ic|timeout}} – menu timeout in seconds. If this is not set, the menu will only be shown when you hold the space key while booting.<br />
<br />
Example:<br />
<br />
{{hc|$esp/loader/loader.conf|<br />
default arch<br />
timeout 4<br />
}}<br />
<br />
Note that both options can be changed in the boot menu itself, which will store them as EFI variables.<br />
<br />
{{Note|If no timeout is configured, which is the default setting, and no key pressed during bootup, the default entry is executed right away.}}<br />
<br />
=== Adding boot entries ===<br />
{{Note|gummiboot will automatically check for "'''Windows Boot Manager'''" ({{ic|\EFI\Microsoft\Boot\Bootmgfw.efi}}), "'''EFI Shell'''" ({{ic|\shellx64.efi}}) and "'''EFI Default Loader'''" ({{ic|\EFI\Boot\bootx64.efi}}). Where detected, entries will also automatically be generated for them as well. However, it does not auto-detect other EFI applications (unlike [[rEFInd]]), so for booting the kernel, manual configuration entries must be created.}}<br />
<br />
{{Tip|You can find the PARTUUID for your Root partition with the command {{ic|1=blkid -s PARTUUID -o value /dev/sdxY}}, where 'x' is the device letter and 'Y' is the partition number. This is required only for your Root partition, not $esp.}}<br />
<br />
gummiboot searches for boot menu items in {{ic|$esp/loader/entries/*.conf}} – each file found must contain exactly one boot entry. The possible options are:<br />
<br />
* {{ic|title}} – operating system name. '''Required.'''<br />
<br />
* {{ic|version}} – kernel version, shown only when multiple entries with same title exist. Optional.<br />
<br />
* {{ic|machine-id}} – machine identifier from {{ic|/etc/machine-id}}, shown only when multiple entries with same title and version exist. Optional.<br />
<br />
* {{ic|efi}} – EFI program to start, relative to your ESP ({{ic|$esp}}); e.g. {{ic|/vmlinuz-linux}}. Either this or {{ic|linux}} (see below) is '''required.'''<br />
<br />
* {{ic|options}} – Command-line options to pass to the EFI program. Optional, but you will need at least {{ic|1=initrd=''efipath''}} and {{ic|1=root=''dev''}} if booting Linux.<br />
<br />
For Linux, you can specify {{ic|linux ''path-to-vmlinuz''}} and {{ic|initrd ''path-to-initramfs''}}; this will be automatically translated to {{ic|efi ''path''}} and {{ic|1=options initrd=''path''}} – this syntax is only supported for convenience and has no differences in function. <br />
<br />
==== Standard Root Installations ====<br />
<br />
Here is an example entry for a root partition without LVM or LUKS:<br />
<br />
{{hc|$esp/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw<br />
}}<br />
<br />
Please note in the example above that PARTUUID/PARTLABEL identifies a GPT partition, and differs from UUID/LABEL, which identifies a filesystem. Using the PARTUUID/PARTLABEL is advantageous because it is invariant (i.e. unchanging) if you reformat the partition with another filesystem, or if the /dev/sd* mapping changed for some reason. It is also useful if you do not have a filesystem on the partition (or use LUKS, which does not support LABELs).<br />
<br />
==== LVM Root Installations ====<br />
<br />
Here is an example for a root partition using [[Lvm| Logical Volume Management]]:<br />
<br />
{{hc|$esp/loader/entries/arch-lvm.conf|2=<br />
title Arch Linux (LVM)<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=/dev/mapper/<VolumeGroup-LogicalVolume> rw<br />
}}<br />
<br />
Replace {{ic|<VolumeGroup-LogicalVolume>}} with the actual VG and LV names (e.g. {{ic|1=root=/dev/mapper/volgroup00-lvolroot}}). Alternatively, it is also possible to use a UUID instead:<br />
....<br />
options root=UUID=<UUID identifier> rw<br />
<br />
Note that {{ic|1=root='''UUID'''=}} is used instead of {{ic|1=root='''PARTUUID'''=}}, which is used for Root partitions without LVM or LUKS.<br />
<br />
==== Encrypted Root Installations ====<br />
<br />
Here is an example configuration file for an encrypted root partition ([[Dm-crypt|DM-Crypt / LUKS]]):<br />
<br />
{{hc|$esp/loader/entries/arch-encrypted.conf|2=<br />
title Arch Linux Encrypted<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options cryptdevice=UUID=<UUID>:luks-<UUID> root=UUID=<luks-UUID> quiet ro<br />
}}<br />
<br />
UUID is used in this example; PARTUUID should be able to replace the UUID, if so desired.<br />
<br />
You can also add other EFI programs such as {{ic|\EFI\arch\grub.efi}}.<br />
<br />
=== Add security ===<br />
<br />
You have to note that the kernel command line parameters can be edited from the gummiboot's boot manager menu (see [[#Keys]]) by pressing {{ic|e}}. This is a major security flaw since if you redefine the {{ic|1=init=}} kernel argument with {{ic|1=init=/bin/bash}} for example, this will boot your machine directly as root without any password, bypassing easily the root password that has been defined! Since gummiboot does not currently have a password feature and has no ability to prevent kernel parameters changes, you need to make sure to define a password at hardware level (UEFI/BIOS) which prevents the computer to boot if the right password has not been entered.<br />
<br />
Since security is made of several levels and physical access already breaks any security systems, maybe encrypting your disk with [[dm-crypt]] would come in handy especially if your machine is a laptop. But this is another concern not related to gummiboot.<br />
<br />
=== Support hibernation ===<br />
<br />
Please refer to that article [[Suspend and hibernate]], especially the [[Suspend and hibernate#Example for gummiboot|Example for gummiboot]].<br />
<br />
== Inside the boot menu ==<br />
<br />
=== Keys ===<br />
<br />
The following keys are used inside the menu:<br />
* {{ic|Up/Down}} - select entry<br />
* {{ic|Enter}} - boot the selected entry<br />
* {{ic|d}} - select the default entry to boot (stored in a non-volatile EFI variable)<br />
* {{ic|-/T}} - decrease the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|+/t}} - increase the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|e}} - edit the kernel command line<br />
* {{ic|v}} - show the gummiboot and UEFI version<br />
* {{ic|Q}} - quit<br />
* {{ic|P}} - print the current configuration<br />
* {{ic|h/?}} - help<br />
<br />
These hotkeys will, when pressed inside the menu or during bootup, directly boot<br />
a specific entry:<br />
<br />
* {{ic|l}} - Linux<br />
* {{ic|w}} - Windows<br />
* {{ic|a}} - OS X<br />
* {{ic|s}} - EFI Shell<br />
* {{ic|1-9}} - number of entry<br />
<br />
== Troubleshooting ==<br />
<br />
=== Manual entry using efibootmgr ===<br />
<br />
If {{ic|gummiboot install}} command failed, you can create a EFI boot entry manually using {{ic|efibootmgr}} utility:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/gummiboot/gummibootx64.efi -L "Gummiboot"<br />
<br />
where {{ic|/dev/sdXY}} is the EFISYS partition.<br />
<br />
=== Menu does not appear after Windows upgrade ===<br />
<br />
For example, if you upgraded from Windows 8 to Windows 8.1, and you no longer see a boot menu after the upgrade (i.e., Windows boots immediately):<br />
* Make sure Secure Boot (BIOS setting) and Fast Startup (Windows power option setting) are both disabled.<br />
* Make sure your BIOS prefers Linux Boot Manager over Windows Boot Manager (depending on your BIOS, this might appear under a BIOS setting like Hard Disk Drive Priority).<br />
<br />
== References ==<br />
<br />
* http://freedesktop.org/wiki/Software/gummiboot/</div>Moviurohttps://wiki.archlinux.org/index.php?title=Android&diff=357106Android2015-01-19T13:55:42Z<p>Moviuro: /* Android SDK core components */ no need to specify user in chmod</p>
<hr />
<div>[[Category:Development]]<br />
[[Category:Mobile devices]]<br />
[[it:Android]]<br />
[[ja:Android]]<br />
[[ru:Android]]<br />
[[zh-CN:Android]]<br />
{{Related articles start}}<br />
{{Related|Android notifier}}<br />
{{Related|Android tethering}}<br />
{{Related articles end}}<br />
<br />
== Exploring Android device ==<br />
<br />
There are few methods of exploring your device:<br />
<br />
*[[MTP]] over USB for files transferring.<br />
*[[#Connecting to a real device - Android Debug Bridge (ADB)|ADB/Fastboot]] for development purposes.<br />
*[[#Alternative connection methods|Alternative methods]] (such as FTP, SSH).<br />
<br />
== Android development ==<br />
<br />
There are 3 steps that need to be performed before you can develop Android applications on your Arch Linux box:<br />
<br />
# Install the Android SDK core component,<br />
# Install one or several Android SDK Platform packages,<br />
# Install one of the IDEs compatible with the Android SDK.<br />
<br />
=== Android SDK core components ===<br />
<br />
{{Note|First, if you are running a 64-bit system, make sure the [[multilib]] repository is enabled in [[Pacman#Repositories|pacman.conf]].}}<br />
<br />
Before developing Android applications, you need to install the Android SDK, which is made of 3 distinct packages, all installable from [[Arch User Repository|AUR]]:<br />
<br />
# {{AUR|android-sdk}}<br />
# {{AUR|android-sdk-platform-tools}}<br />
# {{AUR|android-sdk-build-tools}}<br />
<br />
Android-sdk will be installed on {{ic|/opt/android-sdk}}. This folder has root permissions, so keep in mind to run sdk manager as root, otherwise you will not be able to install/update/modify anything on /opt/android-sdk. However, if you intend to use it as a regular user, create an android sdk users group (or use any group name you want):<br />
# groupadd sdkusers<br />
<br />
Add your user into this group:<br />
# gpasswd -a <user> sdkusers<br />
<br />
Change folder's owner and group.<br />
# chown -R :sdkusers /opt/android-sdk/<br />
<br />
Change permissions of the folder so you will be able to read/write/execute in it:<br />
# chmod -R g+w /opt/android-sdk/<br />
<br />
{{Note|As an alternative to a global install with the [[AUR]] packages, the SDK can be installed to a user's home directory via [https://developer.android.com/sdk/index.html the upstream instructions].}}<br />
<br />
=== Android SDK platform API ===<br />
<br />
Install the desired Android SDK Platform package from the [[AUR]]:<br />
<br />
* {{aur|android-platform}} (latest)<br />
* {{aur|android-platform-21}}<br />
* {{aur|android-platform-20}}<br />
* {{aur|android-platform-19}}<br />
* {{aur|android-platform-18}}<br />
* {{aur|android-platform-17}}<br />
* {{aur|android-platform-16}}<br />
* {{aur|android-platform-15}}<br />
* {{aur|android-platform-14}}<br />
* {{aur|android-platform-13}}<br />
* {{aur|android-platform-12}}<br />
* {{aur|android-platform-11}}<br />
* {{aur|android-platform-10}}<br />
* {{aur|android-platform-9}}<br />
* {{aur|android-platform-8}}<br />
* {{aur|android-platform-7}}<br />
* {{aur|android-platform-7}}<br />
* {{aur|android-platform-6}}<br />
* {{aur|android-platform-5}}<br />
* {{aur|android-platform-4}}<br />
* {{aur|android-platform-3}}<br />
* {{aur|android-platform-2}}<br />
<br />
=== Development environment ===<br />
<br />
Android Studio is the new official Android development environment based on IntelliJ IDEA. Alternatively, you can use [[Eclipse]] with the official but deprecated ADT plugin, or [[Netbeans]] with the NBAndroid plugin. All are described below.<br />
<br />
==== Android Studio ====<br />
<br />
[http://developer.android.com/sdk/installing/studio.html Android Studio] is the new official Android development environment based on IntelliJ IDEA. Similar to Eclipse with the ADT Plugin, Android Studio provides integrated Android developer tools for development and debugging.<br />
<br />
You can download and install it with the {{AUR|android-studio}} package from the AUR. If you get an error about a missing SDK, refer to the section Getting Android SDK platform API above.<br />
<br />
If you are using a tiling window manager, you will need to apply one of the fixes mentioned in [https://code.google.com/p/android/issues/detail?id=57675 this] issue page.<br />
<br />
==== Eclipse ====<br />
<br />
{{Note|Since 2014-12-08, the ADT plugin is officially considered deprecated and Android Studio is now the official IDE.}}<br />
<br />
Most stuff required for Android development in Eclipse is already packaged in AUR:<br />
<br />
Official plugin by Google &ndash; [http://developer.android.com/sdk/eclipse-adt.html Eclipse ADT]:<br />
# {{AUR|eclipse-android}}<br />
<br />
Dependencies:<br />
# {{AUR|eclipse-emf}}<br />
# {{AUR|eclipse-gef}}<br />
# {{AUR|eclipse-wtp}}<br />
<br />
{{Note|<br />
* if you get a message about unresolvable dependencies, install [[Java]] manually and try again.<br />
* as an alternative, you can install the ADT via eclipse's built in "add new software" command (see instructions on ADT site).<br />
* if you are in real trouble, it is also possible to download Android SDK and use the bundled Eclipse. This usually works without problems.<br />
* if you need to install extra SDK plugins not found in the AUR, you must change the file ownership of /opt/android-sdk first. You can do this with {{ic|# chgrp -R users /opt/android-sdk ; chmod -R 0775 /opt/android-sdk}} (see [[File Permissions]] for more details).<br />
}}<br />
<br />
Enter the path to the Android SDK Location in<br />
<br />
Windows -> Preferences -> Android<br />
<br />
{{Note|<br />
If the plugins do not show up in Eclipse after the AUR package has been upgraded, then eclipse probably has out-of-date caches. Running {{ic|sudo eclipse -clean}} once should clear them. If the problem persists, uninstall eclipse and all the plugins, delete {{ic|/usr/share/eclipse}}, and reinstall everything.<br />
}}<br />
<br />
==== Netbeans ====<br />
<br />
If you prefer using [[Netbeans]] as your IDE and want to develop Android applications, download the [http://www.nbandroid.org NBAndroid] by going to:<br />
<br />
Tools -> Plugins -> Settings<br />
<br />
Add the following URL: http://nbandroid.org/updates/updates.xml<br />
<br />
Then go to '''Available Plugins''' and install the '''Android''' and '''JUnit''' plugins. Once you have installed go to:<br />
<br />
Tools -> Options -> Miscellaneous -> Android<br />
<br />
and select the path where the SDK is installed (/opt/android-sdk by default). That is it, now you can create a new Android project and start developing using Netbeans.<br />
<br />
=== Connecting to a real device - Android Debug Bridge (ADB) ===<br />
<br />
{{Tip|For some devices, you may have to enable MTP on the device, before ADB will work.}}<br />
<br />
To get ADB to connect to a real device or phone under Arch, you must:<br />
<br />
* Install {{Pkg|android-tools}}.<br />
* Enable USB Debugging on your phone or device:<br />
** Jelly Bean (4.2) and newer: Go to {{ic|Settings --> About Phone}} tap “Build Number” until you get a popup that you have become a developer (about 10 times). Then go to {{ic|Settings --> Developer --> USB debugging}} and enable it.<br />
** Older versions: This is usually done from {{ic|Settings --> Applications --> Development --> USB debugging}}. Reboot the phone after checking this option to make sure USB debugging is enabled.<br />
* install {{Pkg|android-udev}} to connect the device to the proper {{ic|/dev/}} entries.<br />
* Add yourself to the ''adbusers'' group. ({{ic|gpasswd -a ''username'' adbusers}})<br />
<br />
If [[#Does it work?|ADB recognizes your device]] (it is visible and accessible in IDE), you are done. Otherwise see instructions below.<br />
<br />
==== Figure out device IDs ====<br />
<br />
Each Android device has a USB vendor/product ID. An example for HTC Evo is:<br />
<br />
vendor id: 0bb4<br />
product id: 0c8d<br />
<br />
Plug in your device and execute:<br />
<br />
$ lsusb<br />
<br />
It should come up something like this:<br />
<br />
Bus 002 Device 006: ID 0bb4:0c8d High Tech Computer Corp.<br />
<br />
==== Adding udev Rules ====<br />
<br />
Use the rules from [http://source.android.com/source/initializing.html#configuring-usb-access Android developer] or you can use the following template for your udev rules, just replace [VENDOR ID] and [PRODUCT ID] with yours. Copy these rules into {{ic|/etc/udev/rules.d/51-android.rules}}:<br />
<br />
{{hc|/etc/udev/rules.d/51-android.rules|2=<nowiki>SUBSYSTEM=="usb", ATTR{idVendor}=="[VENDOR ID]", MODE="0666"<br />
SUBSYSTEM=="usb",ATTR{idVendor}=="[VENDOR ID]",ATTR{idProduct}=="[PRODUCT ID]",SYMLINK+="android_adb"<br />
SUBSYSTEM=="usb",ATTR{idVendor}=="[VENDOR ID]",ATTR{idProduct}=="[PRODUCT ID]",SYMLINK+="android_fastboot"</nowiki>}}<br />
<br />
Then, to reload your new udev rules, execute:<br />
# udevadm control --reload-rules<br />
<br />
==== Configuring adb ====<br />
<br />
Instead of using udev rules, you may create/edit {{ic|~/.android/adb_usb.ini}} which contains a list of vendor IDs.<br />
<br />
$ cat ~/.android/adb_usb.ini <br />
0x27e8<br />
<br />
==== Does it work? ====<br />
<br />
After you have setup the udev rules, unplug your device and replug it.<br />
<br />
After running:<br />
<br />
$ adb devices<br />
<br />
you should see something like:<br />
<br />
List of devices attached <br />
HT07VHL00676 device<br />
<br />
You can now use adb to transfer files between the device and your computer. To transfer files to the device, use<br />
$ adb push ''<what-to-copy>'' ''<where-to-place>''<br />
<br />
To transfer files from the device, use<br />
$ adb pull ''<what-to-pull>'' ''<where-to-place>''<br />
<br />
If you do not have the '''adb''' program (usually available in {{Ic|/opt/android-sdk/platform-tools/}}), it means you have not installed the platform tools.<br />
<br />
If you are getting an empty list (your device is not there), it may be because you have not enabled USB debugging on your device. You can do that by going to Settings => Applications => Development and enabling USB debugging. On Android 4.2 (Jelly Bean) the Development menu is hidden; to enable it go to Settings => About phone and tap Build number 7 times.<br />
<br />
If there are still problems such as ''adb'' displaying {{ic|???????? no permissions}} under devices, try restarting the adb server as root.<br />
# adb kill-server<br />
# adb start-server<br />
<br />
=== NVIDIA Tegra platform ===<br />
<br />
If you target your application at NVIDIA Tegra platform, you might also want to install tools, samples and documentation provided by NVIDIA. In [http://developer.nvidia.com/category/zone/mobile-development NVIDIA Developer Zone for Mobile] there are two tools: <br />
<br />
# The [http://developer.nvidia.com/tegra-resources Tegra Android Development Pack] provides tools (NVIDIA Debug Manager) related to [http://developer.android.com/sdk/eclipse-adt.html Eclipse ADT] and their documentation. <br />
# The [http://developer.nvidia.com/tegra-resources Tegra Toolkit] provides tools (mostly CPU and GPU optimization related), samples and documentation. <br />
<br />
Both are currently not available in the [[AUR]] anymore, because NVIDIA requires a registration/login for the download.<br />
<br />
== Building Android ==<br />
<br />
Please note that these instructions are based on the [http://source.android.com/source/building.html official AOSP build instructions]. Other Android-derived systems such as CyanogenMod will often require extra steps.<br />
<br />
=== OS bitness ===<br />
<br />
Android 2.2.x (Froyo) and below are the only versions of Android that will build on a 32-bit system. For 2.3.x (Gingerbread) and above, you will need a 64-bit installation. <br />
<br />
=== Required packages ===<br />
<br />
To build any version of Android, you need to install these packages:<br />
<br />
* 32-bit and 64-bit systems: {{Pkg|gcc}} {{Pkg|git}} {{Pkg|gnupg}} {{Pkg|flex}} {{Pkg|bison}} {{Pkg|gperf}} {{Pkg|sdl}} {{Pkg|wxgtk}} {{Pkg|squashfs-tools}} {{Pkg|curl}} {{Pkg|ncurses}} {{Pkg|zlib}} {{Pkg|schedtool}} {{Pkg|perl-switch}} {{Pkg|zip}} {{Pkg|unzip}} {{Pkg|libxslt}} {{Pkg|python2-virtualenv}} {{Pkg|bc}}<br />
<br />
* 64-bit systems only: {{Pkg|gcc-multilib}} {{Pkg|lib32-zlib}} {{Pkg|lib32-ncurses}} {{Pkg|lib32-readline}}<br />
<br />
=== Java Development Kit ===<br />
<br />
Android 5 (Lollipop) can be built with {{Pkg|jdk7-openjdk}}.<br />
<br />
Older versions [http://source.android.com/source/initializing.html require] a working '''Oracle JDK''' installed on your build system. It '''will not''' work with OpenJDK.<br />
*For Gingerbread through KitKat (2.3 - 4.4), Java 6 is required, which is available as {{AUR|jdk6}} from the AUR. See [[Java]] if you want to use it besides another (newer) JDK version.<br />
*For Cupcake through Froyo (1.5 - 2.2), Java 5 is required, which is no longer available for Arch Linux.<br />
<br />
=== Setting up the build environment ===<br />
<br />
Download the {{ic|repo}} utility.<br />
<br />
$ mkdir ~/bin<br />
$ export PATH=~/bin:$PATH<br />
$ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo<br />
$ chmod a+x ~/bin/repo<br />
<br />
Create a directory to build.<br />
<br />
$ mkdir ~/android<br />
$ cd ~/android<br />
<br />
You will need to change the default Python from version 3 to version 2:<br />
<br />
$ virtualenv2 venv # Creates a directory, venv/, containing the Virtualenv<br />
<br />
{{Note|During build you may receive error pertaining to missing python modules. A quick and dirty fix is to symlink /usr/lib/python2.7/* to ~/android/venv/python2.7/ (Change ~/android to reflect your build directory if different than above).<br />
Example:<br />
$ ln -s /usr/lib/python2.7/* /Data/Android_Build/venv/lib/python2.7/<br />
}}<br />
Activate the Virtualenv, which will update $PATH to point at Python 2.<br />
<br />
{{Note|this activation is only active for the current terminal session.<br />
}}<br />
<br />
$ source venv/bin/activate<br />
<br />
=== Downloading the source code ===<br />
<br />
This will clone the repositories. You '''only''' need to do this the first time you build Android, or if you want to switch branches.<br />
<br />
* The {{ic|repo}} has a {{ic|-j}} switch that operates similarly to the one used with {{ic|make}}. Since it controls the number of simultaneous downloads, you should adjust the value depending on downstream network bandwidth.<br />
<br />
* You will need to specify a '''branch''' (release of Android) to check out with the {{ic|-b}} switch. If you leave the switch out, you will get the so-called '''master branch'''.<br />
<br />
$ repo init -u https://android.googlesource.com/platform/manifest -b master<br />
$ repo sync -j4<br />
<br />
Wait a long time. Just the uncompiled source code, along with the {{ic|.repo}} and {{ic|.git}} directories that are used to keep track of it, are well over 10 GB.<br />
<br />
{{Note|If you want to update your local copy of the Android source, at a later time, simply enter the build directory, load the Virtualenv, and re-sync:<br />
$ repo sync<br />
}}<br />
<br />
=== Building the code ===<br />
<br />
This should do what you need for AOSP:<br />
<br />
$ source build/envsetup.sh<br />
$ lunch full-eng<br />
$ make -j4<br />
<br />
If you run '''lunch''' without arguments, it will ask what build you want to create. Use -j with a number between one and two times number of cores/threads.<br />
<br />
The build takes a very long time.<br />
<br />
{{Note|Make sure you have enough RAM.<br />
Android will use the /tmp directory heavily. By default the size of the partition the /tmp folder is mounted on is half the size of your RAM. If it fills up, the build will fail. 4GB of RAM or more is recommended.<br />
* Alternatively, you can get rid of the tmpfs from [[Fstab|fstab]] all together. <br />
}}<br />
<br />
=== Testing the build ===<br />
<br />
When finished, run/test the final image(s).<br />
<br />
$ emulator<br />
<br />
=== Creating a Flashable Image ===<br />
To create an image that can be flashed it is necessary to:<br />
<br />
make -j8 updatepackage<br />
<br />
This will create a zip image under '''out/target/product/hammerhead''' (hammerhead being the device name) that can be flashed.<br />
<br />
== Alternative connection methods ==<br />
<br />
=== AirDroid ===<br />
<br />
AirDroid is an Android app to access files from your web browser.<br />
<br />
=== FTP ===<br />
<br />
You run a FTP server on Arch and connect to it from your phone, or the other way around: run a FTP server on your phone and connect to it from Arch.<br />
<br />
See [[List of applications/Internet#FTP]]. There are a lot of FTP clients/servers available for Android.<br />
<br />
=== SSH Server ===<br />
<br />
There are many SSH servers available for Android, it allows you to transfer files using {{ic|scp}} command. See also [[SSH]].<br />
<br />
=== Samba ===<br />
<br />
See [[Samba]].<br />
<br />
== Tips & Tricks ==<br />
<br />
=== During Debugging "Source not found" ===<br />
<br />
Most probably the debugger wants to step into the Java code. As the source code of Android does not come with the Android SDK, this leads to an error. The best solution is to use step filters to not jump into the Java source code. Step filters are not activated by default. To activate them: <br />
Window -> Preferences -> Java -> Debug -> Step Filtering<br />
Consider to select them all. If appropriate you can add the android.* package. See the forum post for more information: http://www.eclipsezone.com/eclipse/forums/t83338.rhtml<br />
<br />
=== Linux distribution on the sdcard ===<br />
<br />
You can install Debian like in this [http://forum.xda-developers.com/showthread.php?t=631389 thread]. Excellent guide to installing Arch in chroot (in parallel with Android) can be found on [http://archlinuxarm.org/forum/viewtopic.php?f=27&t=1361&start=40 archlinuxarm.org forum].<br />
<br />
== Troubleshooting ==<br />
<br />
=== aapt: No such file or directory ===<br />
<br />
The build tools include 32-bit binaries. For this reason they require 32-bit libraries. If you happened to install the SDK manually, you will additionally need to install<br />
'''multilib/lib32-libstdc++5''' and '''multilib/lib32-zlib'''.<br />
<br />
=== ValueError: unsupported pickle protocoll ===<br />
<br />
Just issue 'rm ~/.repopickle_.gitconfig'</div>Moviurohttps://wiki.archlinux.org/index.php?title=Android&diff=357105Android2015-01-19T13:54:34Z<p>Moviuro: /* Android SDK core components */ you crazy or what? DON'T EVER chmod -R <numbers></p>
<hr />
<div>[[Category:Development]]<br />
[[Category:Mobile devices]]<br />
[[it:Android]]<br />
[[ja:Android]]<br />
[[ru:Android]]<br />
[[zh-CN:Android]]<br />
{{Related articles start}}<br />
{{Related|Android notifier}}<br />
{{Related|Android tethering}}<br />
{{Related articles end}}<br />
<br />
== Exploring Android device ==<br />
<br />
There are few methods of exploring your device:<br />
<br />
*[[MTP]] over USB for files transferring.<br />
*[[#Connecting to a real device - Android Debug Bridge (ADB)|ADB/Fastboot]] for development purposes.<br />
*[[#Alternative connection methods|Alternative methods]] (such as FTP, SSH).<br />
<br />
== Android development ==<br />
<br />
There are 3 steps that need to be performed before you can develop Android applications on your Arch Linux box:<br />
<br />
# Install the Android SDK core component,<br />
# Install one or several Android SDK Platform packages,<br />
# Install one of the IDEs compatible with the Android SDK.<br />
<br />
=== Android SDK core components ===<br />
<br />
{{Note|First, if you are running a 64-bit system, make sure the [[multilib]] repository is enabled in [[Pacman#Repositories|pacman.conf]].}}<br />
<br />
Before developing Android applications, you need to install the Android SDK, which is made of 3 distinct packages, all installable from [[Arch User Repository|AUR]]:<br />
<br />
# {{AUR|android-sdk}}<br />
# {{AUR|android-sdk-platform-tools}}<br />
# {{AUR|android-sdk-build-tools}}<br />
<br />
Android-sdk will be installed on {{ic|/opt/android-sdk}}. This folder has root permissions, so keep in mind to run sdk manager as root, otherwise you will not be able to install/update/modify anything on /opt/android-sdk. However, if you intend to use it as a regular user, create an android sdk users group (or use any group name you want):<br />
# groupadd sdkusers<br />
<br />
Add your user into this group:<br />
# gpasswd -a <user> sdkusers<br />
<br />
Change folder's owner and group.<br />
# chown -R <user>:sdkusers /opt/android-sdk/<br />
<br />
Change permissions of the folder so you will be able to read/write/execute in it:<br />
# chmod -R g+w /opt/android-sdk/<br />
<br />
{{Note|As an alternative to a global install with the [[AUR]] packages, the SDK can be installed to a user's home directory via [https://developer.android.com/sdk/index.html the upstream instructions].}}<br />
<br />
=== Android SDK platform API ===<br />
<br />
Install the desired Android SDK Platform package from the [[AUR]]:<br />
<br />
* {{aur|android-platform}} (latest)<br />
* {{aur|android-platform-21}}<br />
* {{aur|android-platform-20}}<br />
* {{aur|android-platform-19}}<br />
* {{aur|android-platform-18}}<br />
* {{aur|android-platform-17}}<br />
* {{aur|android-platform-16}}<br />
* {{aur|android-platform-15}}<br />
* {{aur|android-platform-14}}<br />
* {{aur|android-platform-13}}<br />
* {{aur|android-platform-12}}<br />
* {{aur|android-platform-11}}<br />
* {{aur|android-platform-10}}<br />
* {{aur|android-platform-9}}<br />
* {{aur|android-platform-8}}<br />
* {{aur|android-platform-7}}<br />
* {{aur|android-platform-7}}<br />
* {{aur|android-platform-6}}<br />
* {{aur|android-platform-5}}<br />
* {{aur|android-platform-4}}<br />
* {{aur|android-platform-3}}<br />
* {{aur|android-platform-2}}<br />
<br />
=== Development environment ===<br />
<br />
Android Studio is the new official Android development environment based on IntelliJ IDEA. Alternatively, you can use [[Eclipse]] with the official but deprecated ADT plugin, or [[Netbeans]] with the NBAndroid plugin. All are described below.<br />
<br />
==== Android Studio ====<br />
<br />
[http://developer.android.com/sdk/installing/studio.html Android Studio] is the new official Android development environment based on IntelliJ IDEA. Similar to Eclipse with the ADT Plugin, Android Studio provides integrated Android developer tools for development and debugging.<br />
<br />
You can download and install it with the {{AUR|android-studio}} package from the AUR. If you get an error about a missing SDK, refer to the section Getting Android SDK platform API above.<br />
<br />
If you are using a tiling window manager, you will need to apply one of the fixes mentioned in [https://code.google.com/p/android/issues/detail?id=57675 this] issue page.<br />
<br />
==== Eclipse ====<br />
<br />
{{Note|Since 2014-12-08, the ADT plugin is officially considered deprecated and Android Studio is now the official IDE.}}<br />
<br />
Most stuff required for Android development in Eclipse is already packaged in AUR:<br />
<br />
Official plugin by Google &ndash; [http://developer.android.com/sdk/eclipse-adt.html Eclipse ADT]:<br />
# {{AUR|eclipse-android}}<br />
<br />
Dependencies:<br />
# {{AUR|eclipse-emf}}<br />
# {{AUR|eclipse-gef}}<br />
# {{AUR|eclipse-wtp}}<br />
<br />
{{Note|<br />
* if you get a message about unresolvable dependencies, install [[Java]] manually and try again.<br />
* as an alternative, you can install the ADT via eclipse's built in "add new software" command (see instructions on ADT site).<br />
* if you are in real trouble, it is also possible to download Android SDK and use the bundled Eclipse. This usually works without problems.<br />
* if you need to install extra SDK plugins not found in the AUR, you must change the file ownership of /opt/android-sdk first. You can do this with {{ic|# chgrp -R users /opt/android-sdk ; chmod -R 0775 /opt/android-sdk}} (see [[File Permissions]] for more details).<br />
}}<br />
<br />
Enter the path to the Android SDK Location in<br />
<br />
Windows -> Preferences -> Android<br />
<br />
{{Note|<br />
If the plugins do not show up in Eclipse after the AUR package has been upgraded, then eclipse probably has out-of-date caches. Running {{ic|sudo eclipse -clean}} once should clear them. If the problem persists, uninstall eclipse and all the plugins, delete {{ic|/usr/share/eclipse}}, and reinstall everything.<br />
}}<br />
<br />
==== Netbeans ====<br />
<br />
If you prefer using [[Netbeans]] as your IDE and want to develop Android applications, download the [http://www.nbandroid.org NBAndroid] by going to:<br />
<br />
Tools -> Plugins -> Settings<br />
<br />
Add the following URL: http://nbandroid.org/updates/updates.xml<br />
<br />
Then go to '''Available Plugins''' and install the '''Android''' and '''JUnit''' plugins. Once you have installed go to:<br />
<br />
Tools -> Options -> Miscellaneous -> Android<br />
<br />
and select the path where the SDK is installed (/opt/android-sdk by default). That is it, now you can create a new Android project and start developing using Netbeans.<br />
<br />
=== Connecting to a real device - Android Debug Bridge (ADB) ===<br />
<br />
{{Tip|For some devices, you may have to enable MTP on the device, before ADB will work.}}<br />
<br />
To get ADB to connect to a real device or phone under Arch, you must:<br />
<br />
* Install {{Pkg|android-tools}}.<br />
* Enable USB Debugging on your phone or device:<br />
** Jelly Bean (4.2) and newer: Go to {{ic|Settings --> About Phone}} tap “Build Number” until you get a popup that you have become a developer (about 10 times). Then go to {{ic|Settings --> Developer --> USB debugging}} and enable it.<br />
** Older versions: This is usually done from {{ic|Settings --> Applications --> Development --> USB debugging}}. Reboot the phone after checking this option to make sure USB debugging is enabled.<br />
* install {{Pkg|android-udev}} to connect the device to the proper {{ic|/dev/}} entries.<br />
* Add yourself to the ''adbusers'' group. ({{ic|gpasswd -a ''username'' adbusers}})<br />
<br />
If [[#Does it work?|ADB recognizes your device]] (it is visible and accessible in IDE), you are done. Otherwise see instructions below.<br />
<br />
==== Figure out device IDs ====<br />
<br />
Each Android device has a USB vendor/product ID. An example for HTC Evo is:<br />
<br />
vendor id: 0bb4<br />
product id: 0c8d<br />
<br />
Plug in your device and execute:<br />
<br />
$ lsusb<br />
<br />
It should come up something like this:<br />
<br />
Bus 002 Device 006: ID 0bb4:0c8d High Tech Computer Corp.<br />
<br />
==== Adding udev Rules ====<br />
<br />
Use the rules from [http://source.android.com/source/initializing.html#configuring-usb-access Android developer] or you can use the following template for your udev rules, just replace [VENDOR ID] and [PRODUCT ID] with yours. Copy these rules into {{ic|/etc/udev/rules.d/51-android.rules}}:<br />
<br />
{{hc|/etc/udev/rules.d/51-android.rules|2=<nowiki>SUBSYSTEM=="usb", ATTR{idVendor}=="[VENDOR ID]", MODE="0666"<br />
SUBSYSTEM=="usb",ATTR{idVendor}=="[VENDOR ID]",ATTR{idProduct}=="[PRODUCT ID]",SYMLINK+="android_adb"<br />
SUBSYSTEM=="usb",ATTR{idVendor}=="[VENDOR ID]",ATTR{idProduct}=="[PRODUCT ID]",SYMLINK+="android_fastboot"</nowiki>}}<br />
<br />
Then, to reload your new udev rules, execute:<br />
# udevadm control --reload-rules<br />
<br />
==== Configuring adb ====<br />
<br />
Instead of using udev rules, you may create/edit {{ic|~/.android/adb_usb.ini}} which contains a list of vendor IDs.<br />
<br />
$ cat ~/.android/adb_usb.ini <br />
0x27e8<br />
<br />
==== Does it work? ====<br />
<br />
After you have setup the udev rules, unplug your device and replug it.<br />
<br />
After running:<br />
<br />
$ adb devices<br />
<br />
you should see something like:<br />
<br />
List of devices attached <br />
HT07VHL00676 device<br />
<br />
You can now use adb to transfer files between the device and your computer. To transfer files to the device, use<br />
$ adb push ''<what-to-copy>'' ''<where-to-place>''<br />
<br />
To transfer files from the device, use<br />
$ adb pull ''<what-to-pull>'' ''<where-to-place>''<br />
<br />
If you do not have the '''adb''' program (usually available in {{Ic|/opt/android-sdk/platform-tools/}}), it means you have not installed the platform tools.<br />
<br />
If you are getting an empty list (your device is not there), it may be because you have not enabled USB debugging on your device. You can do that by going to Settings => Applications => Development and enabling USB debugging. On Android 4.2 (Jelly Bean) the Development menu is hidden; to enable it go to Settings => About phone and tap Build number 7 times.<br />
<br />
If there are still problems such as ''adb'' displaying {{ic|???????? no permissions}} under devices, try restarting the adb server as root.<br />
# adb kill-server<br />
# adb start-server<br />
<br />
=== NVIDIA Tegra platform ===<br />
<br />
If you target your application at NVIDIA Tegra platform, you might also want to install tools, samples and documentation provided by NVIDIA. In [http://developer.nvidia.com/category/zone/mobile-development NVIDIA Developer Zone for Mobile] there are two tools: <br />
<br />
# The [http://developer.nvidia.com/tegra-resources Tegra Android Development Pack] provides tools (NVIDIA Debug Manager) related to [http://developer.android.com/sdk/eclipse-adt.html Eclipse ADT] and their documentation. <br />
# The [http://developer.nvidia.com/tegra-resources Tegra Toolkit] provides tools (mostly CPU and GPU optimization related), samples and documentation. <br />
<br />
Both are currently not available in the [[AUR]] anymore, because NVIDIA requires a registration/login for the download.<br />
<br />
== Building Android ==<br />
<br />
Please note that these instructions are based on the [http://source.android.com/source/building.html official AOSP build instructions]. Other Android-derived systems such as CyanogenMod will often require extra steps.<br />
<br />
=== OS bitness ===<br />
<br />
Android 2.2.x (Froyo) and below are the only versions of Android that will build on a 32-bit system. For 2.3.x (Gingerbread) and above, you will need a 64-bit installation. <br />
<br />
=== Required packages ===<br />
<br />
To build any version of Android, you need to install these packages:<br />
<br />
* 32-bit and 64-bit systems: {{Pkg|gcc}} {{Pkg|git}} {{Pkg|gnupg}} {{Pkg|flex}} {{Pkg|bison}} {{Pkg|gperf}} {{Pkg|sdl}} {{Pkg|wxgtk}} {{Pkg|squashfs-tools}} {{Pkg|curl}} {{Pkg|ncurses}} {{Pkg|zlib}} {{Pkg|schedtool}} {{Pkg|perl-switch}} {{Pkg|zip}} {{Pkg|unzip}} {{Pkg|libxslt}} {{Pkg|python2-virtualenv}} {{Pkg|bc}}<br />
<br />
* 64-bit systems only: {{Pkg|gcc-multilib}} {{Pkg|lib32-zlib}} {{Pkg|lib32-ncurses}} {{Pkg|lib32-readline}}<br />
<br />
=== Java Development Kit ===<br />
<br />
Android 5 (Lollipop) can be built with {{Pkg|jdk7-openjdk}}.<br />
<br />
Older versions [http://source.android.com/source/initializing.html require] a working '''Oracle JDK''' installed on your build system. It '''will not''' work with OpenJDK.<br />
*For Gingerbread through KitKat (2.3 - 4.4), Java 6 is required, which is available as {{AUR|jdk6}} from the AUR. See [[Java]] if you want to use it besides another (newer) JDK version.<br />
*For Cupcake through Froyo (1.5 - 2.2), Java 5 is required, which is no longer available for Arch Linux.<br />
<br />
=== Setting up the build environment ===<br />
<br />
Download the {{ic|repo}} utility.<br />
<br />
$ mkdir ~/bin<br />
$ export PATH=~/bin:$PATH<br />
$ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo<br />
$ chmod a+x ~/bin/repo<br />
<br />
Create a directory to build.<br />
<br />
$ mkdir ~/android<br />
$ cd ~/android<br />
<br />
You will need to change the default Python from version 3 to version 2:<br />
<br />
$ virtualenv2 venv # Creates a directory, venv/, containing the Virtualenv<br />
<br />
{{Note|During build you may receive error pertaining to missing python modules. A quick and dirty fix is to symlink /usr/lib/python2.7/* to ~/android/venv/python2.7/ (Change ~/android to reflect your build directory if different than above).<br />
Example:<br />
$ ln -s /usr/lib/python2.7/* /Data/Android_Build/venv/lib/python2.7/<br />
}}<br />
Activate the Virtualenv, which will update $PATH to point at Python 2.<br />
<br />
{{Note|this activation is only active for the current terminal session.<br />
}}<br />
<br />
$ source venv/bin/activate<br />
<br />
=== Downloading the source code ===<br />
<br />
This will clone the repositories. You '''only''' need to do this the first time you build Android, or if you want to switch branches.<br />
<br />
* The {{ic|repo}} has a {{ic|-j}} switch that operates similarly to the one used with {{ic|make}}. Since it controls the number of simultaneous downloads, you should adjust the value depending on downstream network bandwidth.<br />
<br />
* You will need to specify a '''branch''' (release of Android) to check out with the {{ic|-b}} switch. If you leave the switch out, you will get the so-called '''master branch'''.<br />
<br />
$ repo init -u https://android.googlesource.com/platform/manifest -b master<br />
$ repo sync -j4<br />
<br />
Wait a long time. Just the uncompiled source code, along with the {{ic|.repo}} and {{ic|.git}} directories that are used to keep track of it, are well over 10 GB.<br />
<br />
{{Note|If you want to update your local copy of the Android source, at a later time, simply enter the build directory, load the Virtualenv, and re-sync:<br />
$ repo sync<br />
}}<br />
<br />
=== Building the code ===<br />
<br />
This should do what you need for AOSP:<br />
<br />
$ source build/envsetup.sh<br />
$ lunch full-eng<br />
$ make -j4<br />
<br />
If you run '''lunch''' without arguments, it will ask what build you want to create. Use -j with a number between one and two times number of cores/threads.<br />
<br />
The build takes a very long time.<br />
<br />
{{Note|Make sure you have enough RAM.<br />
Android will use the /tmp directory heavily. By default the size of the partition the /tmp folder is mounted on is half the size of your RAM. If it fills up, the build will fail. 4GB of RAM or more is recommended.<br />
* Alternatively, you can get rid of the tmpfs from [[Fstab|fstab]] all together. <br />
}}<br />
<br />
=== Testing the build ===<br />
<br />
When finished, run/test the final image(s).<br />
<br />
$ emulator<br />
<br />
=== Creating a Flashable Image ===<br />
To create an image that can be flashed it is necessary to:<br />
<br />
make -j8 updatepackage<br />
<br />
This will create a zip image under '''out/target/product/hammerhead''' (hammerhead being the device name) that can be flashed.<br />
<br />
== Alternative connection methods ==<br />
<br />
=== AirDroid ===<br />
<br />
AirDroid is an Android app to access files from your web browser.<br />
<br />
=== FTP ===<br />
<br />
You run a FTP server on Arch and connect to it from your phone, or the other way around: run a FTP server on your phone and connect to it from Arch.<br />
<br />
See [[List of applications/Internet#FTP]]. There are a lot of FTP clients/servers available for Android.<br />
<br />
=== SSH Server ===<br />
<br />
There are many SSH servers available for Android, it allows you to transfer files using {{ic|scp}} command. See also [[SSH]].<br />
<br />
=== Samba ===<br />
<br />
See [[Samba]].<br />
<br />
== Tips & Tricks ==<br />
<br />
=== During Debugging "Source not found" ===<br />
<br />
Most probably the debugger wants to step into the Java code. As the source code of Android does not come with the Android SDK, this leads to an error. The best solution is to use step filters to not jump into the Java source code. Step filters are not activated by default. To activate them: <br />
Window -> Preferences -> Java -> Debug -> Step Filtering<br />
Consider to select them all. If appropriate you can add the android.* package. See the forum post for more information: http://www.eclipsezone.com/eclipse/forums/t83338.rhtml<br />
<br />
=== Linux distribution on the sdcard ===<br />
<br />
You can install Debian like in this [http://forum.xda-developers.com/showthread.php?t=631389 thread]. Excellent guide to installing Arch in chroot (in parallel with Android) can be found on [http://archlinuxarm.org/forum/viewtopic.php?f=27&t=1361&start=40 archlinuxarm.org forum].<br />
<br />
== Troubleshooting ==<br />
<br />
=== aapt: No such file or directory ===<br />
<br />
The build tools include 32-bit binaries. For this reason they require 32-bit libraries. If you happened to install the SDK manually, you will additionally need to install<br />
'''multilib/lib32-libstdc++5''' and '''multilib/lib32-zlib'''.<br />
<br />
=== ValueError: unsupported pickle protocoll ===<br />
<br />
Just issue 'rm ~/.repopickle_.gitconfig'</div>Moviurohttps://wiki.archlinux.org/index.php?title=Systemd-boot&diff=349504Systemd-boot2014-12-11T07:52:14Z<p>Moviuro: /* Legacy boot */ Added note</p>
<hr />
<div>{{DISPLAYTITLE:gummiboot}}<br />
[[Category:Boot loaders]]<br />
[[de:Gummiboot]]<br />
[[es:Gummiboot]]<br />
[[ja:Gummiboot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related articles end}}<br />
<br />
From [http://freedesktop.org/wiki/Software/gummiboot/ gummiboot homepage]:<br />
:''gummiboot is a simple UEFI boot manager which executes configured EFI images. The default entry is selected by a configured pattern (glob) or an on-screen menu''.<br />
<br />
It is simple to configure, but can only start EFI executables, the Linux kernel [[EFISTUB]], UEFI Shell, grub.efi, and such.<br />
<br />
{{Warning|gummiboot simply provides a boot menu for EFISTUB kernels. In case you have issues booting EFISTUB kernels like in {{Bug|33745}}, you should use a boot loader which does not use EFISTUB, like [[GRUB]], [[Syslinux]] or [[Bootloaders#ELILO|ELILO]].}}<br />
<br />
{{Note|In the entire article {{ic|$esp}} denotes the mountpoint of the [[UEFI#EFI System Partition|EFI System Partition]] aka ESP.}}<br />
<br />
== Installation ==<br />
<br />
=== EFI boot ===<br />
First, make sure you are booted in UEFI mode, [[UEFI#Requirements for UEFI Variables support to work properly|your EFI variables are accessible]], your EFI System Partition is properly mounted and your kernel and initramfs are copied onto that ESP as gummiboot cannot load EFI binaries from other partitions. It is therefore strongly recommended to mount your ESP to {{ic|/boot}} if you use gummiboot.<br />
<br />
Then, [[install]] the package {{Pkg|gummiboot}} from the [[official repositories]].<br />
<br />
Finally, type the following command to copy the gummiboot binary to your EFI System Partition and add gummiboot itself as the default EFI application (default boot entry) loaded by the EFI Boot Manager. If you are not booted in UEFI mode and your EFI variables are not accessible, creating the boot entry will fail. You should however still be able to boot gummiboot as it copies the binary to the default EFI binary location on your ESP ({{ic|$esp/EFI/boot/bootx64.efi}} on x64 systems) unless a non-gummiboot EFI application is already present as the same filename.<br />
<br />
# gummiboot --path=''$esp'' install<br />
<br />
=== Legacy boot ===<br />
{{Note|This is not the recommended process}}<br />
You can also successfully install gummiboot if booted with a legacy OS. However, this requires that you later on tell your firmware to launch gummiboot's EFI file on boot:<br />
* you have a working EFI shell somewhere;<br />
* your firmware interface provides you with a way of properly setting the EFI file that will be loaded at boot time. {{Note|This is for example possible on Dell's Latitude series that will simply refuse you touch the firmware with an EFI shell}}<br />
If you can do so, the installation is easier: [[install]] {{Pkg|gummiboot}} from the [[official repositories]], go into your EFI shell or your firmware configuration interface and change your machine's defualt EFI file to {{ic|/<EFI boot partition>/efi/gummiboot/gummibootx64.efi}}.<br />
<br />
=== Updating ===<br />
<br />
gummiboot assumes that your EFI System Partition is mounted on {{ic|/boot}} in which case, each time a new gummiboot version is installed, the command {{ic|1=gummiboot --path=''$esp'' update}} will be called automatically by the {{ic|post_install}} method of the install script. If your ESP is not mounted on {{ic|/boot}}, you will have to call manually that command.<br />
<br />
== Configuration ==<br />
<br />
=== Basic Configuration ===<br />
<br />
The basic configuration is kept in {{ic|$esp/loader/loader.conf}}, with just two possible configuration options:<br />
<br />
* {{ic|default}} – default entry to select (without the {{ic|.conf}} suffix); can be a wildcard like {{ic|arch-*}}<br />
<br />
* {{ic|timeout}} – menu timeout in seconds. If this is not set, the menu will only be shown when you hold the space key while booting.<br />
<br />
Example:<br />
<br />
{{hc|$esp/loader/loader.conf|<br />
default arch<br />
timeout 4<br />
}}<br />
<br />
Note that both options can be changed in the boot menu itself, which will store them as EFI variables.<br />
<br />
{{Note|If no timeout is configured, which is the default setting, and no key pressed during bootup, the default entry is executed right away.}}<br />
<br />
=== Adding boot entries ===<br />
<br />
gummiboot searches for boot menu items in {{ic|$esp/loader/entries/*.conf}} – each file found must contain exactly one boot entry. The possible options are:<br />
<br />
* {{ic|title}} – operating system name. '''Required.'''<br />
<br />
* {{ic|version}} – kernel version, shown only when multiple entries with same title exist. Optional.<br />
<br />
* {{ic|machine-id}} – machine identifier from {{ic|/etc/machine-id}}, shown only when multiple entries with same title and version exist. Optional.<br />
<br />
* {{ic|efi}} – EFI program to start, relative to your ESP ({{ic|$esp}}); e.g. {{ic|/vmlinuz-linux}}. Either this or {{ic|linux}} (see below) is '''required.'''<br />
<br />
* {{ic|options}} – Command-line options to pass to the EFI program. Optional, but you will need at least {{ic|1=initrd=''efipath''}} and {{ic|1=root=''dev''}} if booting Linux.<br />
<br />
For Linux, you can specify {{ic|linux ''path-to-vmlinuz''}} and {{ic|initrd ''path-to-initramfs''}}; this will be automatically translated to {{ic|efi ''path''}} and {{ic|1=options initrd=''path''}} – this syntax is only supported for convenience and has no differences in function. <br />
<br />
You can find your PARTUUID with {{ic|1=blkid -s PARTUUID -o value /dev/sdxx}} (/dev/sdxx should be your root partition and not $esp)<br />
<br />
An example entry for Arch Linux:<br />
<br />
{{hc|$esp/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw<br />
}}<br />
<br />
Please note in the example above that PARTUUID/PARTLABEL identifies a GPT partition, and differs from UUID/LABEL, which identifies a filesystem. Using the PARTUUID/PARTLABEL is advantageous because it is invariant if you reformat the partition with another filesystem or the /dev/sd* mapping changed for some reason. It is also useful if you do not have a filesystem on the partition (or use LUKS, which does not support LABELs).<br />
<br />
An example entry for encrypted root (dm-crypt with LUKS)<br />
{{hc|$esp/loader/entries/arch-encrypted.conf|2=<br />
title Arch Linux (Encrypted)<br />
linux /path/to/vmlinuz-linux<br />
options initrd=/path/to/initramfs-linux.img cryptdevice=UUID=<UUID>:luks-<UUID> root=UUID=<luks-UUID> rw<br />
}}<br />
<br />
In the encrypted example, note that the initrd is in options -- this does not appear to be discretionary at this time. Note that UUID is used for in this example. PARTUUID should be able to replace the UUID, if so desired.<br />
<br />
You can also add other EFI programs such as {{ic|\EFI\arch\grub.efi}}.<br />
<br />
{{Note|gummiboot will automatically check for "'''Windows Boot Manager'''" ({{ic|\EFI\Microsoft\Boot\Bootmgfw.efi}}), "'''EFI Shell'''" ({{ic|\shellx64.efi}}) and "'''EFI Default Loader'''" ({{ic|\EFI\Boot\bootx64.efi}}), and display entries for them if they are present, so you do not have to manually create entries for them. However it does not autodetect other EFI applications (unlike rEFInd), so for booting the kernel, manual config entries must be created as mentioned above.}}<br />
<br />
=== Add security ===<br />
<br />
You have to note that the kernel command line parameters can be edited from the gummiboot's boot manager menu (see [[#Keys]]) by pressing {{ic|e}}. This is a major security flaw since if you redefine the {{ic|1=init=}} kernel argument with {{ic|1=init=/bin/bash}} for example, this will boot your machine directly as root without any password, bypassing easily the root password that has been defined! Since gummiboot does not currently have a password feature and has no ability to prevent kernel parameters changes, you need to make sure to define a password at hardware level (UEFI/BIOS) which prevents the computer to boot if the right password has not been entered.<br />
<br />
Since security is made of several levels and physical access already breaks any security systems, maybe encrypting your disk with [[dm-crypt]] would come in handy especially if your machine is a laptop. But this is another concern not related to gummiboot.<br />
<br />
=== Support hibernation ===<br />
<br />
Please refer to that article [[Suspend and hibernate]], especially the [[Suspend and hibernate#Example for gummiboot|Example for gummiboot]].<br />
<br />
== Inside the boot menu ==<br />
<br />
=== Keys ===<br />
<br />
The following keys are used inside the menu:<br />
* {{ic|Up/Down}} - select entry<br />
* {{ic|Enter}} - boot the selected entry<br />
* {{ic|d}} - select the default entry to boot (stored in a non-volatile EFI variable)<br />
* {{ic|-/T}} - decrease the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|+/t}} - increase the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|e}} - edit the kernel command line<br />
* {{ic|v}} - show the gummiboot and UEFI version<br />
* {{ic|Q}} - quit<br />
* {{ic|P}} - print the current configuration<br />
* {{ic|h/?}} - help<br />
<br />
These hotkeys will, when pressed inside the menu or during bootup, directly boot<br />
a specific entry:<br />
<br />
* {{ic|l}} - Linux<br />
* {{ic|w}} - Windows<br />
* {{ic|a}} - OS X<br />
* {{ic|s}} - EFI Shell<br />
* {{ic|1-9}} - number of entry<br />
<br />
== Troubleshooting ==<br />
<br />
=== Manual entry using efibootmgr ===<br />
<br />
If {{ic|gummiboot install}} command failed, you can create a EFI boot entry manually using {{ic|efibootmgr}} utility:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/gummiboot/gummibootx64.efi -L "Gummiboot"<br />
<br />
where {{ic|/dev/sdXY}} is the EFISYS partition.<br />
<br />
=== Menu does not appear after Windows upgrade ===<br />
<br />
For example, if you upgraded from Windows 8 to Windows 8.1, and you no longer see a boot menu after the upgrade (i.e., Windows boots immediately):<br />
* Make sure Secure Boot (BIOS setting) and Fast Startup (Windows power option setting) are both disabled.<br />
* Make sure your BIOS prefers Linux Boot Manager over Windows Boot Manager (depending on your BIOS, this might appear under a BIOS setting like Hard Disk Drive Priority).<br />
<br />
== References ==<br />
<br />
* http://freedesktop.org/wiki/Software/gummiboot/</div>Moviurohttps://wiki.archlinux.org/index.php?title=Systemd-boot&diff=348202Systemd-boot2014-12-04T22:10:32Z<p>Moviuro: /* EFI boot */ typo</p>
<hr />
<div>{{DISPLAYTITLE:gummiboot}}<br />
[[Category:Boot loaders]]<br />
[[de:Gummiboot]]<br />
[[es:Gummiboot]]<br />
[[ja:Gummiboot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related articles end}}<br />
<br />
From [http://freedesktop.org/wiki/Software/gummiboot/ gummiboot homepage]:<br />
:''gummiboot is a simple UEFI boot manager which executes configured EFI images. The default entry is selected by a configured pattern (glob) or an on-screen menu''.<br />
<br />
It is simple to configure, but can only start EFI executables, the Linux kernel [[EFISTUB]], UEFI Shell, grub.efi, and such.<br />
<br />
{{Warning|gummiboot simply provides a boot menu for EFISTUB kernels. In case you have issues booting EFISTUB kernels like in {{Bug|33745}}, you should use a boot loader which does not use EFISTUB, like [[GRUB]], [[Syslinux]] or [[Bootloaders#ELILO|ELILO]].}}<br />
<br />
{{Note|In the entire article {{ic|$esp}} denotes the mountpoint of the [[UEFI#EFI System Partition|EFI System Partition]] aka ESP.}}<br />
<br />
== Installation ==<br />
<br />
=== EFI boot ===<br />
First, make sure you are booted in UEFI mode, [[UEFI#Requirements for UEFI Variables support to work properly|your EFI variables are accessible]], your EFI System Partition is properly mounted and your kernel and initramfs are copied onto that ESP as gummiboot cannot load EFI binaries from other partitions. It is therefore strongly recommended to mount your ESP to {{ic|/boot}} if you use gummiboot.<br />
<br />
Then, [[install]] the package {{Pkg|gummiboot}} from the [[official repositories]].<br />
<br />
Finally, type the following command to copy the gummiboot binary to your EFI System Partition and add gummiboot itself as the default EFI application (default boot entry) loaded by the EFI Boot Manager. If you are not booted in UEFI mode and your EFI variables are not accessible, creating the boot entry will fail. You should however still be able to boot gummiboot as it copies the binary to the default EFI binary location on your ESP ({{ic|$esp/EFI/boot/bootx64.efi}} on x64 systems) unless a non-gummiboot EFI application is already present as the same filename.<br />
<br />
# gummiboot --path=''$esp'' install<br />
<br />
=== Legacy boot ===<br />
You can also successfully install gummiboot if booted with a legacy OS. However, this requires that you later on tell your firmware to launch gummiboot's EFI file on boot:<br />
* you have a working EFI shell somewhere;<br />
* your firmware interface provides you with a way of properly setting the EFI file that will be loaded at boot time. {{Note|This is for example possible on Dell's Latitude series that will simply refuse you touch the firmware with an EFI shell}}<br />
If you can do so, the installation is easier: [[install]] {{Pkg|gummiboot}} from the [[official repositories]], go into your EFI shell or your firmware configuration interface and change your machine's defualt EFI file to {{ic|/<EFI boot partition>/efi/gummiboot/gummibootx64.efi}}.<br />
<br />
=== Updating ===<br />
<br />
gummiboot assumes that your EFI System Partition is mounted on {{ic|/boot}} in which case, each time a new gummiboot version is installed, the command {{ic|1=gummiboot --path=''$esp'' update}} will be called automatically by the {{ic|post_install}} method of the install script. If your ESP is not mounted on {{ic|/boot}}, you will have to call manually that command.<br />
<br />
== Configuration ==<br />
<br />
=== Basic Configuration ===<br />
<br />
The basic configuration is kept in {{ic|$esp/loader/loader.conf}}, with just two possible configuration options:<br />
<br />
* {{ic|default}} – default entry to select (without the {{ic|.conf}} suffix); can be a wildcard like {{ic|arch-*}}<br />
<br />
* {{ic|timeout}} – menu timeout in seconds. If this is not set, the menu will only be shown when you hold the space key while booting.<br />
<br />
Example:<br />
<br />
{{hc|$esp/loader/loader.conf|<br />
default arch<br />
timeout 4<br />
}}<br />
<br />
Note that both options can be changed in the boot menu itself, which will store them as EFI variables.<br />
<br />
{{Note|If no timeout is configured, which is the default setting, and no key pressed during bootup, the default entry is executed right away.}}<br />
<br />
=== Adding boot entries ===<br />
<br />
gummiboot searches for boot menu items in {{ic|$esp/loader/entries/*.conf}} – each file found must contain exactly one boot entry. The possible options are:<br />
<br />
* {{ic|title}} – operating system name. '''Required.'''<br />
<br />
* {{ic|version}} – kernel version, shown only when multiple entries with same title exist. Optional.<br />
<br />
* {{ic|machine-id}} – machine identifier from {{ic|/etc/machine-id}}, shown only when multiple entries with same title and version exist. Optional.<br />
<br />
* {{ic|efi}} – EFI program to start, relative to your ESP ({{ic|$esp}}); e.g. {{ic|/vmlinuz-linux}}. Either this or {{ic|linux}} (see below) is '''required.'''<br />
<br />
* {{ic|options}} – Command-line options to pass to the EFI program. Optional, but you will need at least {{ic|1=initrd=''efipath''}} and {{ic|1=root=''dev''}} if booting Linux.<br />
<br />
For Linux, you can specify {{ic|linux ''path-to-vmlinuz''}} and {{ic|initrd ''path-to-initramfs''}}; this will be automatically translated to {{ic|efi ''path''}} and {{ic|1=options initrd=''path''}} – this syntax is only supported for convenience and has no differences in function. <br />
<br />
You can find your PARTUUID with {{ic|1=blkid -s PARTUUID -o value /dev/sdxx}} (/dev/sdxx should be your root partition and not $esp)<br />
<br />
An example entry for Arch Linux:<br />
<br />
{{hc|$esp/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw<br />
}}<br />
<br />
Please note in the example above that PARTUUID/PARTLABEL identifies a GPT partition, and differs from UUID/LABEL, which identifies a filesystem. Using the PARTUUID/PARTLABEL is advantageous because it is invariant if you reformat the partition with another filesystem or the /dev/sd* mapping changed for some reason. It is also useful if you do not have a filesystem on the partition (or use LUKS, which does not support LABELs).<br />
<br />
An example entry for encrypted root (dm-crypt with LUKS)<br />
{{hc|$esp/loader/entries/arch-encrypted.conf|2=<br />
title Arch Linux (Encrypted)<br />
linux /path/to/vmlinuz-linux<br />
options initrd=/path/to/initramfs-linux.img cryptdevice=UUID=<UUID>:luks-<UUID> root=UUID=<luks-UUID> rw<br />
}}<br />
<br />
In the encrypted example, note that the initrd is in options -- this does not appear to be discretionary at this time. Note that UUID is used for in this example. PARTUUID should be able to replace the UUID, if so desired.<br />
<br />
You can also add other EFI programs such as {{ic|\EFI\arch\grub.efi}}.<br />
<br />
{{Note|gummiboot will automatically check for "'''Windows Boot Manager'''" ({{ic|\EFI\Microsoft\Boot\Bootmgfw.efi}}), "'''EFI Shell'''" ({{ic|\shellx64.efi}}) and "'''EFI Default Loader'''" ({{ic|\EFI\Boot\bootx64.efi}}), and display entries for them if they are present, so you do not have to manually create entries for them. However it does not autodetect other EFI applications (unlike rEFInd), so for booting the kernel, manual config entries must be created as mentioned above.}}<br />
<br />
=== Add security ===<br />
<br />
You have to note that the kernel command line parameters can be edited from the gummiboot's boot manager menu (see [[#Keys]]) by pressing {{ic|e}}. This is a major security flaw since if you redefine the {{ic|1=init=}} kernel argument with {{ic|1=init=/bin/bash}} for example, this will boot your machine directly as root without any password, bypassing easily the root password that has been defined! Since gummiboot does not currently have a password feature and has no ability to prevent kernel parameters changes, you need to make sure to define a password at hardware level (UEFI/BIOS) which prevents the computer to boot if the right password has not been entered.<br />
<br />
Since security is made of several levels and physical access already breaks any security systems, maybe encrypting your disk with [[dm-crypt]] would come in handy especially if your machine is a laptop. But this is another concern not related to gummiboot.<br />
<br />
=== Support hibernation ===<br />
<br />
Please refer to that article [[Suspend and hibernate]], especially the [[Suspend and hibernate#Example for gummiboot|Example for gummiboot]].<br />
<br />
== Inside the boot menu ==<br />
<br />
=== Keys ===<br />
<br />
The following keys are used inside the menu:<br />
* {{ic|Up/Down}} - select entry<br />
* {{ic|Enter}} - boot the selected entry<br />
* {{ic|d}} - select the default entry to boot (stored in a non-volatile EFI variable)<br />
* {{ic|-/T}} - decrease the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|+/t}} - increase the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|e}} - edit the kernel command line<br />
* {{ic|v}} - show the gummiboot and UEFI version<br />
* {{ic|Q}} - quit<br />
* {{ic|P}} - print the current configuration<br />
* {{ic|h/?}} - help<br />
<br />
These hotkeys will, when pressed inside the menu or during bootup, directly boot<br />
a specific entry:<br />
<br />
* {{ic|l}} - Linux<br />
* {{ic|w}} - Windows<br />
* {{ic|a}} - OS X<br />
* {{ic|s}} - EFI Shell<br />
* {{ic|1-9}} - number of entry<br />
<br />
== Troubleshooting ==<br />
<br />
=== Manual entry using efibootmgr ===<br />
<br />
If {{ic|gummiboot install}} command failed, you can create a EFI boot entry manually using {{ic|efibootmgr}} utility:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/gummiboot/gummibootx64.efi -L "Gummiboot"<br />
<br />
where {{ic|/dev/sdXY}} is the EFISYS partition.<br />
<br />
=== Menu does not appear after Windows upgrade ===<br />
<br />
For example, if you upgraded from Windows 8 to Windows 8.1, and you no longer see a boot menu after the upgrade (i.e., Windows boots immediately):<br />
* Make sure Secure Boot (BIOS setting) and Fast Startup (Windows power option setting) are both disabled.<br />
* Make sure your BIOS prefers Linux Boot Manager over Windows Boot Manager (depending on your BIOS, this might appear under a BIOS setting like Hard Disk Drive Priority).<br />
<br />
== References ==<br />
<br />
* http://freedesktop.org/wiki/Software/gummiboot/</div>Moviurohttps://wiki.archlinux.org/index.php?title=Systemd-boot&diff=348201Systemd-boot2014-12-04T22:09:30Z<p>Moviuro: /* Legacy boot */ typo, using a list, made sure the note is linked to the good item</p>
<hr />
<div>{{DISPLAYTITLE:gummiboot}}<br />
[[Category:Boot loaders]]<br />
[[de:Gummiboot]]<br />
[[es:Gummiboot]]<br />
[[ja:Gummiboot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related articles end}}<br />
<br />
From [http://freedesktop.org/wiki/Software/gummiboot/ gummiboot homepage]:<br />
:''gummiboot is a simple UEFI boot manager which executes configured EFI images. The default entry is selected by a configured pattern (glob) or an on-screen menu''.<br />
<br />
It is simple to configure, but can only start EFI executables, the Linux kernel [[EFISTUB]], UEFI Shell, grub.efi, and such.<br />
<br />
{{Warning|gummiboot simply provides a boot menu for EFISTUB kernels. In case you have issues booting EFISTUB kernels like in {{Bug|33745}}, you should use a boot loader which does not use EFISTUB, like [[GRUB]], [[Syslinux]] or [[Bootloaders#ELILO|ELILO]].}}<br />
<br />
{{Note|In the entire article {{ic|$esp}} denotes the mountpoint of the [[UEFI#EFI System Partition|EFI System Partition]] aka ESP.}}<br />
<br />
== Installation ==<br />
<br />
=== EFI boot ===<br />
First, make sure your are booted in UEFI mode, [[UEFI#Requirements for UEFI Variables support to work properly|your EFI variables are accessible]], your EFI System Partition is properly mounted and your kernel and initramfs are copied onto that ESP as gummiboot cannot load EFI binaries from other partitions. It is therefore strongly recommended to mount your ESP to {{ic|/boot}} if you use gummiboot.<br />
<br />
Then, [[install]] the package {{Pkg|gummiboot}} from the [[official repositories]].<br />
<br />
Finally, type the following command to copy the gummiboot binary to your EFI System Partition and add gummiboot itself as the default EFI application (default boot entry) loaded by the EFI Boot Manager. If you are not booted in UEFI mode and your EFI variables are not accessible, creating the boot entry will fail. You should however still be able to boot gummiboot as it copies the binary to the default EFI binary location on your ESP ({{ic|$esp/EFI/boot/bootx64.efi}} on x64 systems) unless a non-gummiboot EFI application is already present as the same filename.<br />
<br />
# gummiboot --path=''$esp'' install<br />
<br />
=== Legacy boot ===<br />
You can also successfully install gummiboot if booted with a legacy OS. However, this requires that you later on tell your firmware to launch gummiboot's EFI file on boot:<br />
* you have a working EFI shell somewhere;<br />
* your firmware interface provides you with a way of properly setting the EFI file that will be loaded at boot time. {{Note|This is for example possible on Dell's Latitude series that will simply refuse you touch the firmware with an EFI shell}}<br />
If you can do so, the installation is easier: [[install]] {{Pkg|gummiboot}} from the [[official repositories]], go into your EFI shell or your firmware configuration interface and change your machine's defualt EFI file to {{ic|/<EFI boot partition>/efi/gummiboot/gummibootx64.efi}}.<br />
<br />
=== Updating ===<br />
<br />
gummiboot assumes that your EFI System Partition is mounted on {{ic|/boot}} in which case, each time a new gummiboot version is installed, the command {{ic|1=gummiboot --path=''$esp'' update}} will be called automatically by the {{ic|post_install}} method of the install script. If your ESP is not mounted on {{ic|/boot}}, you will have to call manually that command.<br />
<br />
== Configuration ==<br />
<br />
=== Basic Configuration ===<br />
<br />
The basic configuration is kept in {{ic|$esp/loader/loader.conf}}, with just two possible configuration options:<br />
<br />
* {{ic|default}} – default entry to select (without the {{ic|.conf}} suffix); can be a wildcard like {{ic|arch-*}}<br />
<br />
* {{ic|timeout}} – menu timeout in seconds. If this is not set, the menu will only be shown when you hold the space key while booting.<br />
<br />
Example:<br />
<br />
{{hc|$esp/loader/loader.conf|<br />
default arch<br />
timeout 4<br />
}}<br />
<br />
Note that both options can be changed in the boot menu itself, which will store them as EFI variables.<br />
<br />
{{Note|If no timeout is configured, which is the default setting, and no key pressed during bootup, the default entry is executed right away.}}<br />
<br />
=== Adding boot entries ===<br />
<br />
gummiboot searches for boot menu items in {{ic|$esp/loader/entries/*.conf}} – each file found must contain exactly one boot entry. The possible options are:<br />
<br />
* {{ic|title}} – operating system name. '''Required.'''<br />
<br />
* {{ic|version}} – kernel version, shown only when multiple entries with same title exist. Optional.<br />
<br />
* {{ic|machine-id}} – machine identifier from {{ic|/etc/machine-id}}, shown only when multiple entries with same title and version exist. Optional.<br />
<br />
* {{ic|efi}} – EFI program to start, relative to your ESP ({{ic|$esp}}); e.g. {{ic|/vmlinuz-linux}}. Either this or {{ic|linux}} (see below) is '''required.'''<br />
<br />
* {{ic|options}} – Command-line options to pass to the EFI program. Optional, but you will need at least {{ic|1=initrd=''efipath''}} and {{ic|1=root=''dev''}} if booting Linux.<br />
<br />
For Linux, you can specify {{ic|linux ''path-to-vmlinuz''}} and {{ic|initrd ''path-to-initramfs''}}; this will be automatically translated to {{ic|efi ''path''}} and {{ic|1=options initrd=''path''}} – this syntax is only supported for convenience and has no differences in function. <br />
<br />
You can find your PARTUUID with {{ic|1=blkid -s PARTUUID -o value /dev/sdxx}} (/dev/sdxx should be your root partition and not $esp)<br />
<br />
An example entry for Arch Linux:<br />
<br />
{{hc|$esp/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw<br />
}}<br />
<br />
Please note in the example above that PARTUUID/PARTLABEL identifies a GPT partition, and differs from UUID/LABEL, which identifies a filesystem. Using the PARTUUID/PARTLABEL is advantageous because it is invariant if you reformat the partition with another filesystem or the /dev/sd* mapping changed for some reason. It is also useful if you do not have a filesystem on the partition (or use LUKS, which does not support LABELs).<br />
<br />
An example entry for encrypted root (dm-crypt with LUKS)<br />
{{hc|$esp/loader/entries/arch-encrypted.conf|2=<br />
title Arch Linux (Encrypted)<br />
linux /path/to/vmlinuz-linux<br />
options initrd=/path/to/initramfs-linux.img cryptdevice=UUID=<UUID>:luks-<UUID> root=UUID=<luks-UUID> rw<br />
}}<br />
<br />
In the encrypted example, note that the initrd is in options -- this does not appear to be discretionary at this time. Note that UUID is used for in this example. PARTUUID should be able to replace the UUID, if so desired.<br />
<br />
You can also add other EFI programs such as {{ic|\EFI\arch\grub.efi}}.<br />
<br />
{{Note|gummiboot will automatically check for "'''Windows Boot Manager'''" ({{ic|\EFI\Microsoft\Boot\Bootmgfw.efi}}), "'''EFI Shell'''" ({{ic|\shellx64.efi}}) and "'''EFI Default Loader'''" ({{ic|\EFI\Boot\bootx64.efi}}), and display entries for them if they are present, so you do not have to manually create entries for them. However it does not autodetect other EFI applications (unlike rEFInd), so for booting the kernel, manual config entries must be created as mentioned above.}}<br />
<br />
=== Add security ===<br />
<br />
You have to note that the kernel command line parameters can be edited from the gummiboot's boot manager menu (see [[#Keys]]) by pressing {{ic|e}}. This is a major security flaw since if you redefine the {{ic|1=init=}} kernel argument with {{ic|1=init=/bin/bash}} for example, this will boot your machine directly as root without any password, bypassing easily the root password that has been defined! Since gummiboot does not currently have a password feature and has no ability to prevent kernel parameters changes, you need to make sure to define a password at hardware level (UEFI/BIOS) which prevents the computer to boot if the right password has not been entered.<br />
<br />
Since security is made of several levels and physical access already breaks any security systems, maybe encrypting your disk with [[dm-crypt]] would come in handy especially if your machine is a laptop. But this is another concern not related to gummiboot.<br />
<br />
=== Support hibernation ===<br />
<br />
Please refer to that article [[Suspend and hibernate]], especially the [[Suspend and hibernate#Example for gummiboot|Example for gummiboot]].<br />
<br />
== Inside the boot menu ==<br />
<br />
=== Keys ===<br />
<br />
The following keys are used inside the menu:<br />
* {{ic|Up/Down}} - select entry<br />
* {{ic|Enter}} - boot the selected entry<br />
* {{ic|d}} - select the default entry to boot (stored in a non-volatile EFI variable)<br />
* {{ic|-/T}} - decrease the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|+/t}} - increase the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|e}} - edit the kernel command line<br />
* {{ic|v}} - show the gummiboot and UEFI version<br />
* {{ic|Q}} - quit<br />
* {{ic|P}} - print the current configuration<br />
* {{ic|h/?}} - help<br />
<br />
These hotkeys will, when pressed inside the menu or during bootup, directly boot<br />
a specific entry:<br />
<br />
* {{ic|l}} - Linux<br />
* {{ic|w}} - Windows<br />
* {{ic|a}} - OS X<br />
* {{ic|s}} - EFI Shell<br />
* {{ic|1-9}} - number of entry<br />
<br />
== Troubleshooting ==<br />
<br />
=== Manual entry using efibootmgr ===<br />
<br />
If {{ic|gummiboot install}} command failed, you can create a EFI boot entry manually using {{ic|efibootmgr}} utility:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/gummiboot/gummibootx64.efi -L "Gummiboot"<br />
<br />
where {{ic|/dev/sdXY}} is the EFISYS partition.<br />
<br />
=== Menu does not appear after Windows upgrade ===<br />
<br />
For example, if you upgraded from Windows 8 to Windows 8.1, and you no longer see a boot menu after the upgrade (i.e., Windows boots immediately):<br />
* Make sure Secure Boot (BIOS setting) and Fast Startup (Windows power option setting) are both disabled.<br />
* Make sure your BIOS prefers Linux Boot Manager over Windows Boot Manager (depending on your BIOS, this might appear under a BIOS setting like Hard Disk Drive Priority).<br />
<br />
== References ==<br />
<br />
* http://freedesktop.org/wiki/Software/gummiboot/</div>Moviurohttps://wiki.archlinux.org/index.php?title=Systemd-boot&diff=348199Systemd-boot2014-12-04T22:06:55Z<p>Moviuro: /* Installation */ It is possible to install gummiboot from a legacy OS - provided you change the firmware's settings after the install</p>
<hr />
<div>{{DISPLAYTITLE:gummiboot}}<br />
[[Category:Boot loaders]]<br />
[[de:Gummiboot]]<br />
[[es:Gummiboot]]<br />
[[ja:Gummiboot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related articles end}}<br />
<br />
From [http://freedesktop.org/wiki/Software/gummiboot/ gummiboot homepage]:<br />
:''gummiboot is a simple UEFI boot manager which executes configured EFI images. The default entry is selected by a configured pattern (glob) or an on-screen menu''.<br />
<br />
It is simple to configure, but can only start EFI executables, the Linux kernel [[EFISTUB]], UEFI Shell, grub.efi, and such.<br />
<br />
{{Warning|gummiboot simply provides a boot menu for EFISTUB kernels. In case you have issues booting EFISTUB kernels like in {{Bug|33745}}, you should use a boot loader which does not use EFISTUB, like [[GRUB]], [[Syslinux]] or [[Bootloaders#ELILO|ELILO]].}}<br />
<br />
{{Note|In the entire article {{ic|$esp}} denotes the mountpoint of the [[UEFI#EFI System Partition|EFI System Partition]] aka ESP.}}<br />
<br />
== Installation ==<br />
<br />
=== EFI boot ===<br />
First, make sure your are booted in UEFI mode, [[UEFI#Requirements for UEFI Variables support to work properly|your EFI variables are accessible]], your EFI System Partition is properly mounted and your kernel and initramfs are copied onto that ESP as gummiboot cannot load EFI binaries from other partitions. It is therefore strongly recommended to mount your ESP to {{ic|/boot}} if you use gummiboot.<br />
<br />
Then, [[install]] the package {{Pkg|gummiboot}} from the [[official repositories]].<br />
<br />
Finally, type the following command to copy the gummiboot binary to your EFI System Partition and add gummiboot itself as the default EFI application (default boot entry) loaded by the EFI Boot Manager. If you are not booted in UEFI mode and your EFI variables are not accessible, creating the boot entry will fail. You should however still be able to boot gummiboot as it copies the binary to the default EFI binary location on your ESP ({{ic|$esp/EFI/boot/bootx64.efi}} on x64 systems) unless a non-gummiboot EFI application is already present as the same filename.<br />
<br />
# gummiboot --path=''$esp'' install<br />
<br />
=== Legacy boot ===<br />
You can also successfully install gummiboot if booted with a legacy OS. However, this requires that you later on tell your firmware to launch gummiboot's EFI file on boot: either you have a working EFI shell somewhere or your firmware interface provides you with a way of properly setting the EFI file that will be loaded at boot time.<br />
{{Note|This is for example possible on Dell's Latitude series that will simply refuse you touch the firmware with an EFI shell}}<br />
If you can do so, the installation is easier: [[install]] {{Pkg|gummiboot}} from the [[official repositories]], go into your EFI shell or your firmware configuration interface and change your machine's defualt EFI file to {{ic|/boot/efi/gummiboot/gummibootx64.efi}}.<br />
<br />
=== Updating ===<br />
<br />
gummiboot assumes that your EFI System Partition is mounted on {{ic|/boot}} in which case, each time a new gummiboot version is installed, the command {{ic|1=gummiboot --path=''$esp'' update}} will be called automatically by the {{ic|post_install}} method of the install script. If your ESP is not mounted on {{ic|/boot}}, you will have to call manually that command.<br />
<br />
== Configuration ==<br />
<br />
=== Basic Configuration ===<br />
<br />
The basic configuration is kept in {{ic|$esp/loader/loader.conf}}, with just two possible configuration options:<br />
<br />
* {{ic|default}} – default entry to select (without the {{ic|.conf}} suffix); can be a wildcard like {{ic|arch-*}}<br />
<br />
* {{ic|timeout}} – menu timeout in seconds. If this is not set, the menu will only be shown when you hold the space key while booting.<br />
<br />
Example:<br />
<br />
{{hc|$esp/loader/loader.conf|<br />
default arch<br />
timeout 4<br />
}}<br />
<br />
Note that both options can be changed in the boot menu itself, which will store them as EFI variables.<br />
<br />
{{Note|If no timeout is configured, which is the default setting, and no key pressed during bootup, the default entry is executed right away.}}<br />
<br />
=== Adding boot entries ===<br />
<br />
gummiboot searches for boot menu items in {{ic|$esp/loader/entries/*.conf}} – each file found must contain exactly one boot entry. The possible options are:<br />
<br />
* {{ic|title}} – operating system name. '''Required.'''<br />
<br />
* {{ic|version}} – kernel version, shown only when multiple entries with same title exist. Optional.<br />
<br />
* {{ic|machine-id}} – machine identifier from {{ic|/etc/machine-id}}, shown only when multiple entries with same title and version exist. Optional.<br />
<br />
* {{ic|efi}} – EFI program to start, relative to your ESP ({{ic|$esp}}); e.g. {{ic|/vmlinuz-linux}}. Either this or {{ic|linux}} (see below) is '''required.'''<br />
<br />
* {{ic|options}} – Command-line options to pass to the EFI program. Optional, but you will need at least {{ic|1=initrd=''efipath''}} and {{ic|1=root=''dev''}} if booting Linux.<br />
<br />
For Linux, you can specify {{ic|linux ''path-to-vmlinuz''}} and {{ic|initrd ''path-to-initramfs''}}; this will be automatically translated to {{ic|efi ''path''}} and {{ic|1=options initrd=''path''}} – this syntax is only supported for convenience and has no differences in function. <br />
<br />
You can find your PARTUUID with {{ic|1=blkid -s PARTUUID -o value /dev/sdxx}} (/dev/sdxx should be your root partition and not $esp)<br />
<br />
An example entry for Arch Linux:<br />
<br />
{{hc|$esp/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw<br />
}}<br />
<br />
Please note in the example above that PARTUUID/PARTLABEL identifies a GPT partition, and differs from UUID/LABEL, which identifies a filesystem. Using the PARTUUID/PARTLABEL is advantageous because it is invariant if you reformat the partition with another filesystem or the /dev/sd* mapping changed for some reason. It is also useful if you do not have a filesystem on the partition (or use LUKS, which does not support LABELs).<br />
<br />
An example entry for encrypted root (dm-crypt with LUKS)<br />
{{hc|$esp/loader/entries/arch-encrypted.conf|2=<br />
title Arch Linux (Encrypted)<br />
linux /path/to/vmlinuz-linux<br />
options initrd=/path/to/initramfs-linux.img cryptdevice=UUID=<UUID>:luks-<UUID> root=UUID=<luks-UUID> rw<br />
}}<br />
<br />
In the encrypted example, note that the initrd is in options -- this does not appear to be discretionary at this time. Note that UUID is used for in this example. PARTUUID should be able to replace the UUID, if so desired.<br />
<br />
You can also add other EFI programs such as {{ic|\EFI\arch\grub.efi}}.<br />
<br />
{{Note|gummiboot will automatically check for "'''Windows Boot Manager'''" ({{ic|\EFI\Microsoft\Boot\Bootmgfw.efi}}), "'''EFI Shell'''" ({{ic|\shellx64.efi}}) and "'''EFI Default Loader'''" ({{ic|\EFI\Boot\bootx64.efi}}), and display entries for them if they are present, so you do not have to manually create entries for them. However it does not autodetect other EFI applications (unlike rEFInd), so for booting the kernel, manual config entries must be created as mentioned above.}}<br />
<br />
=== Add security ===<br />
<br />
You have to note that the kernel command line parameters can be edited from the gummiboot's boot manager menu (see [[#Keys]]) by pressing {{ic|e}}. This is a major security flaw since if you redefine the {{ic|1=init=}} kernel argument with {{ic|1=init=/bin/bash}} for example, this will boot your machine directly as root without any password, bypassing easily the root password that has been defined! Since gummiboot does not currently have a password feature and has no ability to prevent kernel parameters changes, you need to make sure to define a password at hardware level (UEFI/BIOS) which prevents the computer to boot if the right password has not been entered.<br />
<br />
Since security is made of several levels and physical access already breaks any security systems, maybe encrypting your disk with [[dm-crypt]] would come in handy especially if your machine is a laptop. But this is another concern not related to gummiboot.<br />
<br />
=== Support hibernation ===<br />
<br />
Please refer to that article [[Suspend and hibernate]], especially the [[Suspend and hibernate#Example for gummiboot|Example for gummiboot]].<br />
<br />
== Inside the boot menu ==<br />
<br />
=== Keys ===<br />
<br />
The following keys are used inside the menu:<br />
* {{ic|Up/Down}} - select entry<br />
* {{ic|Enter}} - boot the selected entry<br />
* {{ic|d}} - select the default entry to boot (stored in a non-volatile EFI variable)<br />
* {{ic|-/T}} - decrease the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|+/t}} - increase the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|e}} - edit the kernel command line<br />
* {{ic|v}} - show the gummiboot and UEFI version<br />
* {{ic|Q}} - quit<br />
* {{ic|P}} - print the current configuration<br />
* {{ic|h/?}} - help<br />
<br />
These hotkeys will, when pressed inside the menu or during bootup, directly boot<br />
a specific entry:<br />
<br />
* {{ic|l}} - Linux<br />
* {{ic|w}} - Windows<br />
* {{ic|a}} - OS X<br />
* {{ic|s}} - EFI Shell<br />
* {{ic|1-9}} - number of entry<br />
<br />
== Troubleshooting ==<br />
<br />
=== Manual entry using efibootmgr ===<br />
<br />
If {{ic|gummiboot install}} command failed, you can create a EFI boot entry manually using {{ic|efibootmgr}} utility:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/gummiboot/gummibootx64.efi -L "Gummiboot"<br />
<br />
where {{ic|/dev/sdXY}} is the EFISYS partition.<br />
<br />
=== Menu does not appear after Windows upgrade ===<br />
<br />
For example, if you upgraded from Windows 8 to Windows 8.1, and you no longer see a boot menu after the upgrade (i.e., Windows boots immediately):<br />
* Make sure Secure Boot (BIOS setting) and Fast Startup (Windows power option setting) are both disabled.<br />
* Make sure your BIOS prefers Linux Boot Manager over Windows Boot Manager (depending on your BIOS, this might appear under a BIOS setting like Hard Disk Drive Priority).<br />
<br />
== References ==<br />
<br />
* http://freedesktop.org/wiki/Software/gummiboot/</div>Moviurohttps://wiki.archlinux.org/index.php?title=Nagios&diff=337168Nagios2014-09-24T21:57:53Z<p>Moviuro: /* Monitor an Archlinux host */ bad name for the AUR link, fixed</p>
<hr />
<div>[[Category:Network monitoring]]<br />
[http://www.nagios.org/ Nagios] is an open source host, service and network monitoring program. It monitors specified hosts and services, alerting you to any developing issues, errors or improvements. This article describes the installation and configuration of Nagios.<br />
<br />
==Features==<br />
Some of Nagios' features [http://nagios.sourceforge.net/docs/3_0/about.html#whatis include]:<br />
*Monitoring of network services (SMTP, POP3, HTTP, NNTP, PING, etc.)<br />
*Monitoring of host resources (processor load, disk usage, etc.)<br />
*Simple plugin design that allows users to easily develop their own service checks<br />
*Parallelized service checks<br />
*Ability to define network host hierarchy using "parent" hosts, allowing detection of and distinction between hosts that are down and those that are unreachable<br />
*Contact notifications when service or host problems occur and get resolved (via email, pager, or user-defined method)<br />
*Ability to define event handlers to be run during service or host events for proactive problem resolution<br />
*Automatic log file rotation<br />
*Support for implementing redundant monitoring hosts<br />
*Optional web interface for viewing current network status, notification and problem history, log file, etc.<br />
<br />
The following installation and configuration were tested using nagios 3.2.0-1, [[Apache]] web server 2.2.14-2, and [[PHP]]5 5.3.1-3 by [https://bbs.archlinux.org/viewtopic.php?id=88461 awayand].<br />
<br />
==Webserver==<br />
According to the [http://nagios.sourceforge.net/docs/3_0/about.html official documentation] a webserver is not required, but if you wish to use any of the CGI features then a webserver (apache preferred), PHP ([[Apache#PHP|php-apache]]) for it and the gd library are required. This is assumed for this installation<br />
<br />
===Installation===<br />
Install {{AUR|nagios}} from the [[AUR]].<br />
<br />
Users may also want to install {{AUR|monitoring-plugins}}.<br />
<br />
===Nagios Configuration===<br />
Copy the sample config files as root:<br />
{{bc|<br />
cp /etc/nagios/cgi.cfg.sample /etc/nagios/cgi.cfg<br />
cp /etc/nagios/resource.cfg.sample /etc/nagios/resource.cfg<br />
cp /etc/nagios/nagios.cfg.sample /etc/nagios/nagios.cfg<br />
cp /etc/nagios/objects/commands.cfg.sample /etc/nagios/objects/commands.cfg<br />
cp /etc/nagios/objects/contacts.cfg.sample /etc/nagios/objects/contacts.cfg<br />
cp /etc/nagios/objects/localhost.cfg.sample /etc/nagios/objects/localhost.cfg<br />
cp /etc/nagios/objects/templates.cfg.sample /etc/nagios/objects/templates.cfg<br />
cp /etc/nagios/objects/timeperiods.cfg.sample /etc/nagios/objects/timeperiods.cfg<br />
}}<br />
<br />
Make owner/group for all the files you just copied and belong to root equal to nagios/nagios:<br />
<br />
{{bc|<br />
# chown -R nagios:nagios /etc/nagios<br />
}}<br />
<br />
Create htpasswd.users file with a username and password, eg. nagiosadmin and secretpass<br />
<br />
{{bc|<br />
# htpasswd -c /etc/nagios/htpasswd.users nagiosadmin<br />
}}<br />
<br />
If you don't want to install apache-tools, you can run following command<br />
<br />
{{bc|<br />
# echo -e "nagiosadmin:`perl -le 'print crypt("your-password","salt")'`" > /etc/nagios/htpasswd.users<br />
}}<br />
<br />
You can also add a different user, but before you can do anything with it in Nagios, you will need to edit {{ic|/etc/nagios/cgi.cfg}}. You can replace 'nagiosadmin' with the desired user, or, you can append it with comma: nagiosadmin,yourusername,yournextusername etc.<br />
<br />
If the owner/group of the nagios-plugins you installed are root:root, the following needs to be done:<br />
<br />
{{bc|<br />
# chown -R nagios:nagios /usr/share/nagios<br />
}}<br />
<br />
Once Nagios is configured, it is time to configure the webserver.<br />
<br />
===Apache Configuration===<br />
Edit /etc/httpd/conf/httpd.conf, add the following to the end of the file:<br />
<br />
{{bc|<br />
LoadModule php5_module modules/libphp5.so<br />
<br />
{{Note|cgi scripts failed for me until i uncommented<br />
LoadModule cgi_module modules/mod_cgi.so}}<br />
<br />
# Nagios<br />
Include "conf/extra/nagios.conf"<br />
<br />
# PHP<br />
Include "conf/extra/php5_module.conf"<br />
<br />
}}<br />
<br />
Copy configure file:<br />
# cp /etc/webapps/nagios/apache.example.conf /etc/httpd/conf/extra/nagios.conf<br />
<br />
Add the apache user http to the group nagios, otherwise you will get the following error when using nagios: <br />
Could not open command file '/var/nagios/rw/nagios.cmd' for update!: <br />
<br />
# usermod -G nagios -a http<br />
<br />
If you are still getting this error, you might need to change the rights on the file:<br />
# chmod 666 /var/nagios/rw/nagios.cmd<br />
<br />
===Nginx Configuration===<br />
Apart from php and php-fpm, You should have [https://wiki.archlinux.org/index.php/Nginx#CGI_implementation fcgiwrap] installed or else CGI scripts won't run.<br />
<br />
Example configuration:<br />
{{bc|<br />
1=server {<br />
server_name nagios.yourdomain.tld;<br />
root /usr/share/nagios/share;<br />
listen 80;<br />
index index.php index.html index.htm;<br />
access_log nagios.access.log;<br />
error_log nagios.error.log;<br />
<br />
auth_basic "Nagios Access";<br />
auth_basic_user_file /etc/nagios/htpasswd.users;<br />
<br />
location ~ \.php$ {<br />
try_files $uri = 404;<br />
fastcgi_index index.php;<br />
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;<br />
include fastcgi.conf;<br />
}<br />
<br />
location ~ \.cgi$ {<br />
root /usr/share/nagios/sbin;<br />
rewrite ^/nagios/cgi-bin/(.*)\.cgi /$1.cgi break;<br />
fastcgi_param AUTH_USER $remote_user;<br />
fastcgi_param REMOTE_USER $remote_user;<br />
include fastcgi.conf;<br />
fastcgi_pass unix:/run/fcgiwrap.sock;<br />
}<br />
<br />
}<br />
}}<br />
===Lighttpd Configuration===<br />
Example for lighttpd:<br />
{{bc|<br />
1=$HTTP["url"] =~ "^/nagios" {<br />
alias.url = (<br />
"/nagios/cgi-bin" => "/usr/share/nagios/sbin",<br />
"/nagios" => "/usr/share/nagios/share" <br />
)<br />
<br />
$HTTP["url"] =~ "^/nagios/cgi-bin" {<br />
cgi.assign = ( "" => "" )<br />
}<br />
<br />
auth.backend = "htpasswd" <br />
auth.backend.htpasswd.userfile = "/etc/nagios/passwd" <br />
auth.require = ( "" => (<br />
"method" => "basic",<br />
"realm" => "nagios",<br />
"require" => "user=nagiosadmin" <br />
)<br />
)<br />
}<br />
}}<br />
<br />
note that mod_setenv, mod_cgi, mod_alias and mod_auth must be allowed.<br />
<br />
===PHP Configuration===<br />
Edit /etc/php/php.ini to include /usr/share/nagios in the open_basedir directive.<br />
<br />
Example configuration:<br />
<br />
{{bc|1=open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps:/etc/webapps:/usr/share/nagios}}<br />
<br />
===Final Steps===<br />
Start/Restart nagios:<br />
<br />
# systemctl restart nagios<br />
<br />
Start/Restart apache:<br />
<br />
# systemctl restart httpd<br />
<br />
Now you should be able to access nagios through your webbrowser using the username and password you have created above using htpasswd:<br />
<br />
http://localhost/nagios<br />
<br />
==Monitor an Archlinux host==<br />
You will need {{AUR|monitoring-plugins}} and {{AUR|nagios-nrpe}} from the [[AUR]] to monitor your host.<br />
<br />
As always when monitoring, the configuration is done in /etc/nrpe/nrpe.cfg and the interesting files to monitor will be in /usr/share/nagios/libexec/ . Don't forget to edit nrpe.cfg as it is mostly empty after install.<br />
<br />
==Plugin check_rdiff==<br />
A small guide on monitoring rdiff-backups using a plugin called check_rdiff.<br />
<br />
===Download and Install===<br />
<br />
You will need perl installed.<br />
<br />
{{bc|<br />
cd<br />
wget http://www.monitoringexchange.org/attachment/download/Check-Plugins/Software/Backup/check_rdiff/check_rdiff<br />
cp check_rdiff /usr/share/nagios/libexec<br />
chown nagios:nagios /usr/share/nagios/libexec/check_rdiff<br />
chmod 755 /usr/share/nagios/libexec/check_rdiff<br />
}}<br />
<br />
===Enable sudo for user nagios===<br />
Since the perl script check_rdiff needs to run as root, you will have to enable sudo for the nagios user:<br />
<br />
{{bc|<br />
sudoedit /etc/sudoers<br />
}}<br />
<br />
This will open the /etc/sudoers file, then paste the following at the end of the file (you should know how to use the vi editor, if that is the one being used by sudoedit):<br />
<br />
{{bc|1=<br />
nagios ALL=(root)NOPASSWD:/usr/share/nagios/libexec/check_rdiff<br />
}}<br />
<br />
===Integrate check_rdiff plugin into nagios===<br />
<br />
Edit /etc/nagios/objects/commands.cfg to include the following command definition:<br />
<br />
{{bc|<br />
# check rdiff-backup<br />
define command{<br />
command_name check_rdiff<br />
command_line sudo $USER1$/check_rdiff -r $ARG1$ -w $ARG2$ -c $ARG3$ -l $ARG4$ -p $ARG5$ <br />
}<br />
}}<br />
<br />
Edit /etc/nagios/objects/localhost.cfg to include checking of rdiff-backup on localhost, for example:<br />
<br />
{{bc|<br />
define service{<br />
use local-service ; Name of service template to use<br />
host_name localhost<br />
service_description rdiff-backup<br />
check_command check_rdiff!/home/x/rdiffbackup!8!10!500!24<br />
}<br />
}}<br />
<br />
Quote from the check_rdiff script content:<br />
<br />
''The above command checks the repository (-r) which is defined as the destination of the backup, or more specifically, the directory above the rdiff-backup-data directory. It will return warning if the backup hasn't finished by 8am and critical by 10am. It will also return warning if the TotalDestinationSizeChange is greater than 500Mb. It also get the period set to 24hrs (-p). This is important as the plugin will throw a critical if the backup doesn't start in time.''<br />
<br />
Finally, restart nagios:<br />
<br />
# systemctl restart nagios<br />
<br />
You can now see the rdiff-backup status by clicking on Services on the left side of the nagios web interface control panel.<br />
<br />
==Forks==<br />
*[[Icinga]] is a Nagios fork. More details about the fork can be found at [https://www.icinga.org/icinga/faq/icinga-vs-nagios/ Icinga FAQ: Why a fork?]<br />
<br />
*[[Naemon]] is the new monitoring suite that aims to be faster and more stable, while giving you a clearer view of the state of your network. [http://www.naemon.org/project.html Naemon FAQ: Why a fork?]<br />
<br />
==See also==<br />
*[http://www.nagios.org/ nagios.org] Official website<br />
*[http://www.nagiosplugins.org/ Nagios Plugins] the home of the official plugins <br />
*[[Wikipedia:Nagios|wikipedia.org]] Wikipedia article<br />
*[http://www.nagiosexchange.org NagiosExchange] overview of plugins, addons, mailing lists for Nagios<br />
*[http://www.nagiosforge.org/ NagiosForge] a repository for ad</div>Moviuro