https://wiki.archlinux.org/api.php?action=feedcontributions&user=ColdPie&feedformat=atomArchWiki - User contributions [en]2024-03-29T09:44:29ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:USB_flash_installation_medium&diff=611065Talk:USB flash installation medium2020-05-05T13:52:37Z<p>ColdPie: /* Repeated editions, back and forth */</p>
<hr />
<div>== About making the installation media without overwriting ==<br />
<br />
I'm not totally sure if I misunderstood something, but I had to change the path of the entries of the *.cfg files. For instance:<br />
<br />
INCLUDE boot/syslinux/archiso_sys.cfg<br />
<br />
became:<br />
<br />
INCLUDE syslinux/archiso_sys.cfg<br />
<br />
It was the only way it worked with the unofficial ISO x86_64 image of march 13th, 2012. Looks like the syslinux command described in the page doesn't get the path as it should. <br />
<br />
I edited all of the .cfg files, but probably only editing this ones should have been enough:<br />
<br />
archiso.cfg<br />
archiso_head.cfg<br />
archiso_sys_inc.cfg<br />
<br />
I hope it could be useful to somebody, because I spend some time with this (I even thought that was a problem with the hardware). I think it could be possible to make a simple script (or give some command lines) to patch the files once they are copied into the USB and run syslinux.<br />
<br />
Thanks !!<br />
:I cannot find that this is still relevant to the article as it now exists. I am striking it out as it looks like it could be good to remove. [[User:AdamT|AdamT]] ([[User talk:AdamT|talk]]) 10:33, 8 August 2013 (UTC)<br />
<br />
::Just lunched from USB drive without UUID(don't have any idea why it didn't have one). Solution was to change label to appropriate in loader/entries/archiso-x86_64.conf. Not sure weither this should be added to article.<br />
--[[User:Versusvoid|Versusvoid]] ([[User talk:Versusvoid|talk]]) 16:00, 18 August 2013 (UTC)<br />
::Versusvoid, I would love to adapt the article but I cannot follow your description above. Looking at that section, it may be out dated. If you are watching this please elaborate when you have time. Thanks, [[User:AdamT|AdamT]] ([[User_talk:AdamT|Talk]]) 08:32, 23 August 2013 (UTC)<br />
<br />
:::Ok. For some reason ubuntu did not see USB UUID. So ''blkid -o value -s UUID /dev/sdx1'' were returning empty string. The solution was:<br />
<br />
:::''$ sed -i "s|label=ARCH_.*|label=$(blkid -o value -s LABEL /dev/sdx1)|" loader/entries/archiso-x86_64.conf''<br />
<br />
:::in the USB mounting directory. --[[User:Versusvoid|Versusvoid]] ([[User talk:Versusvoid|talk]]) 08:05, 31 August 2013 (UTC)<br />
<br />
:::It seems that sometimes you have to get the UUID by running the command as root. --[[User:Rongmu|Rongmu]] ([[User talk:Rongmu|talk]]) 11:23, 3 October 2013 (UTC)<br />
::::Thank you for the follow-up. My semester started so I have not had much of a chance to help with the Arch Wiki of late. I am removing the strike from this section until I can take a closer look and update the article. [[User:AdamT|AdamT]] ([[User_talk:AdamT|Talk]]) 02:02, 16 November 2013 (UTC)<br />
<br />
== Making an UEFI/BIOS ISO should be KISS ==<br />
<br />
Following up on the discussion in the [https://bbs.archlinux.org/viewtopic.php?id=173559 the bbs], I disagree that [https://wiki.archlinux.org/index.php?title=Talk:USB_Flash_Installation_Media&oldid=284705 this edit] should be kept as the first thing users see when hitting this page. I based this opinion on my feeling that the instructions are too many steps and, arguably too vague. Example, this method is 7 steps (depending on how you count) and requires that user read linked articles (i.e syslinux install and modifying master boot records). In contrast, the dd method is simple (KISS principal) and is both [https://projects.archlinux.org/archiso.git/commit/?id=f19f6173c8650ebc43dc166ee2a2f3f92a753afe implemented] and [https://projects.archlinux.org/archiso.git/commit/?id=ce9c853292e0d37e3931634f43ce697ccd33ad11 documented] as pointed out by one of our developers in the aforementioned bbs thread.<br />
<br />
I think we should at least start the article with the KISS method and this edit down the page. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 10:30, 29 November 2013 (UTC)<br />
<br />
: Well, I have been keeping an eye on this since the.ridikulus.rat's extensive edits on and after 2013-11-20. I have kept quiet because the maintainers and admins seemed to accept the changes. However, from the start, I disagreed along lines similar to what Graysky has mentioned above.<br />
<br />
: I did not, and do not, understand why the Arch Wiki should be recommending a specific method without any references or firm reasoning. Instead the.ridikulus.rat seemed to be prescribing a method that was believed was superior based on their own preferences. ''This method is slightly more complicated than writing the image directly with {{ic|dd}}, but it does keep the drive usable for data storage.''<br />
<br />
: <s>Please note this quote from the [https://bbs.archlinux.org/viewtopic.php?pid=1354844#p1354844 BBS thread] Graysky linked above (emphasis mine): ''It took me some time to read through the syslinux docs and other blog [sic] to understand the syslinux installation process under Windows, and '''I don't appreciate you simply removing the entire part that I thought out and typed for the sake of the community.'''''</s> I just realized I completely mistook what the.ridikulus.rat meant to say here. Please disregard.<br />
<br />
: While I do think the technical information that the.ridikulus.rat provided was needed in general, and I had in fact [[Talk:Unified_Extensible_Firmware_Interface#Migrate_UEFI_Bootable_Media_to_USB_Flash_Installation_Media.3F|proposed something similar]] shortly before, the extensive reordering of the page and the subjective recommendations does not seem in keeping with the [[ArchWiki:About|ideals]] and [[Help:Editing|established processes]] of the Arch Wiki as I understand them. <br />
<br />
: <s>Further, referencing the quote above, egos definitely seem to be coming into play in a place where they should not matter. The sake of the community is what matters here, not individual investments. See also [[The Arch Way]].</s><br />
<br />
: Moving forward, as of this writing, the changes that Teateawhy has been making seem to be in keeping with the practices put forth in the Arch Wiki's documentation while also mitigating the subjective recommendation that was put forth during the.ridikulus.rat's changes.<br />
<br />
: As a fairly new contributor, one aspect I have not been able to determine from reading over the Arch Wiki's documentation is when and how to make recommendations. As such, and keeping an eye on the bigger picture here, I would like to take this opportunity to suggest something be added to [[Help:Style]] or elsewhere regarding when and how recommendations and suggestions are justified. There seems to be a willingness for some contributors to make claims without references or supporting statements. Similar to Wikipedia's "reference needed" template, a flag or at least cohesive policy may be warranted for the Arch Wiki and it may help prevent situations like this in the future! : )<br />
<br />
: Cheers all, [[User:AdamT|AdamT]] ([[User_talk:AdamT|Talk]]) 03:17, 30 November 2013 (UTC)<br />
<br />
: I agree that dd is the easiest method, but I would like to use the manual method in order to use a USB drive also as data storage. I'm not new to Linux by a long shot, but the text is so garbled up that I can't successfully follow the manual method... [[User:Jrg2718]], 07 May 2014<br />
<br />
=== Side notes ===<br />
<br />
I don't want to hijack the main discussion, but I'd like to answer a couple of AdamT's observations:<br />
<br />
* please do not assume that admins and maintainers can follow everything that happens on the wiki; if you have something to say about somebody else's edits just do it ;)<br />
* I'd be glad to add some guidelines about recommendations to the style guide; the problem is that it's still very subjective to distinguish between what is a ''justified'' recommendation and what is a ''personal'' recommendation... Technically The.ridikulus.rat did justify his suggestion. If you have an idea for the wording of an effective style guide, please propose it here or in [[Help talk:Style]], but I think that most of these cases will have to be solved in discussion pages like it's happened here.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 01:34, 1 December 2013 (UTC)<br />
<br />
== Other Methods for BIOS systems ==<br />
<br />
Do we really need these provided that dd just works? I suggest deletion of them as outdated. [[User:SkyBon|SkyBon]] ([[User talk:SkyBon|talk]]) 15:12, 28 January 2014 (UTC)<br />
<br />
:Are they outdated, i.e. you're sure they don't work? Otherwise I don't see the reason to delete them, we let users choose their preferred method. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:55, 29 January 2014 (UTC)<br />
<br />
== Graphical dd methods for Linux and Windows ==<br />
<br />
Hi from Fedoraland, Arch folks! I just finished updating the [https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB Fedora wiki page for doing USB writing] - with some references from the rather good SUSE pages on the same topic - [http://en.opensuse.org/SDB:Live_USB_stick main page], [http://en.opensuse.org/SDB:Create_a_Live_USB_stick_using_Windows Windows], [http://en.opensuse.org/SDB:Create_a_Live_USB_stick_using_Mac_OS_x OS X]. I think Arch, Fedora and SUSE all prefer a 'dd' style writing method, so we can take cues from each other here. The Fedora and SUSE pages both now feature ways to do a dd-style write on Windows and OS X, and the Fedora page has a rather convenient method for doing a dd-style write from GNOME - perhaps Arch might like to pick these up too? Could be handy for your users. I tested the recommended Windows tools (SUSE's Studio writer, and rawrite32) on a Windows laptop, and they both clearly did a clean direct write of the image, with Fedora's complex disk label setup to ensure BIOS, UEFI and Mac boot all work kept intact. i.e., they don't screw crap up like unetbootin or that Ubuntu tool does.<br />
<br />
I suppose we could even think about providing a unified set of instructions / tools somewhere - there's quite a bit of redundancy going on at the moment. Thanks! [[User:AdamW|AdamW]] ([[User talk:AdamW|talk]]) 19:06, 30 January 2014 (UTC)<br />
<br />
:Hi AdamW, thank you for your work and for trying to involve our community! For the moment I've referenced the Fedora and openSUSE articles from our See also section, however let's keep this discussion open to see if somebody wants to adapt the methods we're missing for Arch on this article. We may even add some Expansion templates where needed, as reminders and to encourage contributions. In alternative, since in general instead of duplicating external sources we prefer to just provide links to them if they're well maintained, we may just add more specific links to the Fedora article in the proper sections.<br />
:Of course it would be great if we managed to reduce the redundancy among our articles with a unified article "somewhere", but the problem would be how to make it easy for our respective wiki users to edit such article without forcing them to register on another wiki (which clearly would instead have the effect of discouraging contributions). Maybe we could keep part of our articles synchronized with a bot?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:25, 1 February 2014 (UTC)<br />
<br />
== dd for windows ==<br />
\\.\ notation is a Microsoft construct. It addresses a device in the DOS namespace. The documentation is here:<br />
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx<br />
<br />
\\? is a dd construct. It means address a device in the NT native namespace.<br />
<br />
Not all devices are available in the DOS namespace and the rules vary between OS versions and partition type codes etc.<br />
[[User:Jnewbigin|Jnewbigin]] ([[User talk:Jnewbigin|talk]]) 01:32, 12 December 2014 (UTC)<br />
<br />
:I tested the \\.\ notation with Windows 10 1607 (OS Build 14393.222) and cygwin but it did not work. Instead I used /dev/sdx and it worked perfect. [[User:Hncr|Hncr]] ([[User talk:Hncr|talk]]) 23:30, 13 October 2016 (UTC)<br />
<br />
== Using Universal USB Installer ==<br />
<br />
This bit of advice doesn't currently work. The media creates fine but when you try to boot, you get exactly into [https://bbs.archlinux.org/viewtopic.php?pid=1344629 this story]. [[User:All3fox|All3fox]] ([[User talk:All3fox|talk]]) 07:41, 13 April 2014 (UTC)<br />
<br />
:The problem and bbs thread with explanation is referenced in [[USB Flash Installation Media#Using Universal USB Installer]] meanwhile. Closing this. Thanks for reporting! --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:55, 16 August 2014 (UTC)<br />
<br />
::Re-opening, wrt the following edition(s) https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&diff=335781&oldid=335762 .<br />
<br />
::I am confused by this specific edition(s). AFAIK, and at least at the time I am writing this (2014Sep), UUI does not support booting on UEFI systems. To be clear, I mean that UUI is aimed to prepare a USB flash drive to initially boot by means of Syslinux under BIOS (with the caveats already mentioned in the wiki article), and UUI does not know how to boot/use syslinux.efi (nor any other UEFI bootloader). Am I misinformed?<br />
<br />
::I am not saying that a USB flash drive, after using UUI, is incapable of booting UEFI hardware, but it is not UUI that makes it happen. So mentioning UEFI in a Note about UUI is slightly confusing (to me).<br />
<br />
::I don't want to undo the editions before I am sure I am not misunderstanding something. So, am I? [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 22:11, 16 September 2014 (UTC)<br />
<br />
:::I wrote the UUI section and came here to ask the same question: this section is about making an Arch boot USB using windows, and is not specific to EFI-bootable USB disks. The goal is just to bootstrap Arch on the system. Once Arch is booted you can set up your permanent storage to boot any way you like. In particular, I have used a UUI-created boot disk to set up a UEFI system many times. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 11:05, 5 January 2015 (UTC)<br />
<br />
:: To test, I used UUI to create a ARCH_201501 USB boot disk, and then proceeded to use it to EFI boot and install a new server. I'm going to remove the Inaccurate warning, since it is itself inaccurate.<br />
<br />
== Syslinux note ==<br />
<br />
-- ''Moved from [[Help:Style]], as the discussion shifted back to this article.'' -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:46, 22 September 2014 (UTC)<br />
<br />
@Ady (reopening): first of all I want to make clear that I didn't write the "own[ing]" argument in an accusing way, it was only meant to explain my point of view, I should have added a smiley at the end, I'll do it now :)<br />
More important, you said we "derail[ed] from the initial goal", but actually I asked you some questions that were very relevant and specific to your edit, and you haven't answered, so I'll paste them here again:<br />
Where exactly is that note inaccurate? Because usually when you feel some deeper explanations are out of place in some article it's because that article's topic is quite different, so the details should belong somewhere else: is it something regarding [[syslinux]]? Because we have an entire article for it, maybe you could add what's needed there and simply link there from the note?<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:49, 17 August 2014 (UTC)<br />
<br />
:@Kynikos, Since the discussion was moved, the focus changed from the more-technical matter to whether using hidden text was/is appropriate (in this particular case). Thus, I thought that perhaps answering those questions here would have been considered off-topic.<br />
<br />
:The referenced Note says "''The above step installs Syslinux's ldlinux.sys to the VBR of the USB partition, sets the partition as "active/boot" in the MBR partition table and writes the MBR boot code to the 1st 440-byte boot code region of the USB.''". As you can see, this Note is not part of a practical step (and therefore, a slight inaccuracy is likely not going to affect a typical reader following the instructions). Yet, there is a purpose for this Note.<br />
<br />
:Users kept asking (including to upstream Syslinux) whether they can skip part of the steps, and just copy over ldlinux.sys (for example, to either install or update SYSLINUX in their USB drives). Moreover, some users didn't even ask; they simply (over)wrote this file and they complained that SYSLINUX (and/or Arch) fails to boot. So the Note is there to prevent this type of behavior / confusion / repeated waste of time. This explains why deleting the referenced Note would not be wise.<br />
<br />
:About the minor inaccuracy... What the SYSLINUX installer does (when performing the specific steps exactly as described in the relevant section of the article) is to:<br />
:* copy ldlinux.{sys,c32};<br />
:* patch the VBR so it can point to the correct block in the device (so ldlinux.sys can be found);<br />
:* set the partition as "active/boot" in the partition table;<br />
:* write the MBR boot code to the 1st 440-byte boot code region of the USB.<br />
<br />
:I want to clarify that the above description is only relevant for the specific section we are referring to. The SYSLINUX/EXTLINUX installers perform different tasks according to different cases.<br />
<br />
:So, there is a minor (technical) background inaccuracy in the Note.<br />
<br />
:Considering the goal of this Note (as I already described it above) in the context of this particular section of this particular article, and considering that the practical steps provided in the article are not affected by this minor inaccuracy, I asked my self (at the time I performed other editions on the article) whether I should also edit the Note. Would I be actually helping a typical reader that is interested in following the steps? With the objective to balance between accuracy and clarity for the typical reader, I decided not to over-complicate the Note with excessive details that in practical terms only would make the section longer without improving the outcome.<br />
<br />
:Adding a link to the [[Syslinux]] article would not improve the practical experience / steps for the user in this case. If anyone wants to find more technical information, they don't need yet another link from that same article to the same Syslinux page. In this article, the typical reader is (and/or should better be) likely focused on the practical steps.<br />
<br />
:Thus, my "hint" was "''This note is not %100 technically accurate, but it is "accurate-enough" so to be able to perform the task.''". For the typical reader trying to follow the practical steps, the procedure is accurate and he will complete the task successfully, so adding an "Accuracy" box would be counterproductive.<br />
<br />
:Generally speaking, I think there are cases where adding 'comments' (aka hidden text) is adequate, but I am perfectly fine following the guidelines in [[Help:Style]]. Lahwaacz's edition formatted the "hint" as "Accuracy" box, going exactly in the opposite direction of what the hint itself was saying (or at least, against the original intention of the comment). This was not beneficial for users, so I deleted the box.<br />
<br />
:Slightly long to read (apologies), but I hope this clarifies the matter. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 10:45, 17 August 2014 (UTC)<br />
<br />
::I see, thanks for explaining, then why not make explicit the reason why the note is there (KISS), like:<br />
::{{Note|<br />
::* Make sure to run the above command in full, which installs Syslinux's {{ic|ldlinux.sys}} to the VBR of the USB partition, sets the partition as "active/boot" in the MBR partition table and writes the MBR boot code to the 1st 440-byte boot code region of the USB. Only copying the file, for example in an attempt to update an existing Syslinux installation, will result in an unbootable device.<br />
::* ...}}<br />
::This way nobody will see the note as useless and delete it.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:50, 19 August 2014 (UTC)<br />
<br />
== "... and install the MBR or GPT partition table to the USB device as described in the page mentioned." ==<br />
<br />
I am somewhat clueless about what page this instruction in [[USB_flash_installation_media#Using_manual_formatting]] is referring to, can anyone clear that up, what is "the page mentioned"? There is no further mentioning of GPT in the article. Also, not clear why it should be necessary to create a partition table on a USB device, which obviously is partitioned already (else, I wouldn't be able to manipulate any files on it). --[[User:Johannes Rohr|Johannes Rohr]] ([[User talk:Johannes Rohr|talk]]) 08:40, 5 February 2015 (UTC)<br />
<br />
:The previous link leads to [[Syslinux#Manual_install]], have you looked there? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:46, 5 February 2015 (UTC)<br />
<br />
::''Also, not clear why it should be necessary to create a partition table on a USB device, which obviously is partitioned already''<br />
<br />
:I think this has to do with UEFI vs. BIOS booting. In the case of the more modern UEFI, you have a special FAT32-formatted boot partition which is labeled EF00 (so there are 2 partitions on the disk). If you're just going to create a BIOS boot USB, then you only need a single partition. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 09:44, 5 February 2015 (UTC)<br />
<br />
== Repeated editions, back and forth ==<br />
<br />
Is there any way to provide the "adequate" commands for each relevant case, so as to avoid these back_and_forth editions?<br />
<br />
[https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&diff=452196&oldid=450793] [https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&diff=423359&oldid=421431] [https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&diff=418452&oldid=416855]<br />
<br />
[[User:Ady|Ady]] ([[User talk:Ady|talk]]) 16:08, 27 September 2016 (UTC)<br />
<br />
:And [https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&curid=2331&diff=453974&oldid=452196 here] we go, again. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 05:20, 15 October 2016 (UTC)<br />
<br />
::I see 4 options here:<br />
:::1. Ban the users in question for edit warring instead of using the talk page, or temporarily lock the page<br />
:::2. Remove the section and link to some OS X resource instead<br />
:::3. Use a different tool like ''cat''<br />
:::4. Mention that you might have to use 1M if 1m doesn't work, or vice-versa.<br />
::I'm inclined to go with 2.<br />
::-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:28, 15 October 2016 (UTC)<br />
<br />
:::Even before I started this Talk section, I already thought I would go with your option 4. I think it should stop the "back and forth", it would be a simple, short and clear addition to the current text, it would respect users that have invested their time to add the whole set of instructions, and the general steps in the section would remain valid, without depending on third-party sites / sources. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 09:53, 15 October 2016 (UTC)<br />
<br />
::[[User:Almax|Almax]] ([[User talk:Almax|talk]]) 12:23, 15 October 2016 (UTC)<br />
:::Guilty as charged. My guess for why back and forth is happening: Linux folks change the block size multiplier to uppercase M when they see it in the wiki (correct syntax for Linux dd) and Mac folks change it to lowercase m (correct syntax for Mac OS/BSD dd; only accepts b, k, m, g, w). The only correct edit for Mac OS is lowercase m, but how to prevent well-meant "corrections"? I support option 4-ish: Add a Note: explicitly explaining that the args are different between the systems and/or explain it when showing the actual dd command. I arrogantly rewrote the whole section yesterday because I found it to be oddly worded, containing redundant steps and not including info about the device's file system not being recognized by Mac OS after writing the arch*.iso to it. I hope the edit is acceptable. I'm new in the Arch community but no newcomer to Macs or Linux.<br />
<br />
<br />
::::Part of the problem is that some users would "extend" certain concepts and/or commands from one OS to another, but other users would interpret this extension differently, or even perform it differently.<br />
<br />
::::For instance, some users would assume that some command in Linux can be executed exactly the same in BSD, with the same expectations / results. Others might assume the same behavior when going from Mac OS X (or whichever similar name would be valid/current at each time) to BSD.<br />
<br />
::::For example, [[User:Agentxp22]] performed at least one of these editions (I re-post here the link for convenience), [https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&diff=418452&oldid=416855] with a summary note:<br />
<blockquote><br />
1m > 1M because BSD dd uses upper case M for MB block size<br />
</blockquote><br />
<br />
::::I am not getting into the matter of which command is correct (and which is not) for each OS. This Talk section is not about that.<br />
<br />
::::I think we should not "fight" such assumptions, because (too) many users have them, and "policing" each edition (not just in one article) is time-consuming and prone to mistakes. Instead, IMO a more practical solution is to just add a relevant minimal paragraph/sentence/note, as suggested by the 4rth alternative solution proposed by Alad, at least in this particular case.<br />
<br />
::::As I said, it should stop the "back and forth" editions, and clarify the procedure/command while avoiding assumptions. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 14:55, 15 October 2016 (UTC)<br />
<br />
And now we have [https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&diff=579124&oldid=578856]. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 15:00, 8 August 2019 (UTC)<br />
<br />
:If no one can find out the correct unit specification for macOS, just remove the {{ic|bs}} parameter entirely and let the macOS users write 512 bytes at a time. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]])<br />
<br />
<br />
:[[User:Ady|Ady]], that was me and now I realize which version of ''dd'' I used, the GNU one. We should use the syntax for the ''default'' version that comes with macOS, which is the FreeBSD version, and optionally add a comment to specify for those that use the [https://www.gnu.org/software/coreutils/coreutils.html coreutils] version. <br />
:From the [https://linux.die.net/man/1/dd GNU man page]:<br />
<br />
BLOCKS and BYTES may be followed by the following multiplicative suffixes: c<br />
=1, w =2, b =512, kB =1000, K =1024, MB =1000*1000, M =1024*1024, xM =M GB<br />
=1000*1000*1000, G =1024*1024*1024, and so on for T, P, E, Z, Y. <br />
<br />
:From the [https://www.freebsd.org/cgi/man.cgi?query=dd&apropos=0&sektion=0&manpath=FreeBSD+12.0-RELEASE+and+Ports&arch=default&format=html FreeBSD man page]:<br />
<br />
Where sizes or speed are specified, a decimal, octal, or hexadecimal num-<br />
ber of bytes is expected. If the number ends with a ``b'', ``k'', ``m'',<br />
``g'', ``t'', ``p'', or ``w'', the number is multiplied by 512, 1024<br />
(1K), 1048576 (1M), 1073741824 (1G), 1099511627776 (1T), 1125899906842624<br />
(1P) or the number of bytes in an integer, respectively. Two or more<br />
numbers may be separated by an ``x'' to indicate a product.<br />
<br />
: — [[User:Goetzc|Goetzc]] ([[User talk:Goetzc|talk]]) 17:21, 11 August 2019 (UTC)<br />
<br />
::I should clarify, again. As I mentioned before, this specific Talk section is not really about which command is correct for each OS; that's a "technical" matter, and in _theory_ it should be quite "easy" to find out the "correct" one.<br />
::The problem is that, once in awhile, someone decides to "correct" the command in the wiki while betting mom's life that the "corrected" command is truly the "correct" one. And then comes another editor with similar bets/claims but with a slightly different command (e.g. "m" vs. "M"), until a third one steps in (or the first one comes back).<br />
::You know, theory vs. practice; relatively few editors would check a Talk page or open a new discussion before performing an edition, especially when their own "bets" are so "absolutely the winner" ones, "no doubt".<br />
::Then comes some fourth editor, suggesting to eliminate the parts of the command that might generate some conflict while being (seemingly) non-essential, until a fifth editor re-adds the same conflicting option/parameter/argument to the command in question.<br />
::There are also those that suggest that "we should just remove everything", even the parts that are relevant and useful. That's until someone else invests the time to re-add something similar, yet again.<br />
::(Note: I'm not trying to be rude in any way to anyone; I'm trying to clarify a point.) My point is: let's try to add a simple sentence/note that would clarify the matter and lead users (and potential wiki editors) to attempt one command, and if it happens to fail, then try the other, while "leaving the text alone" (instead of this "back_and_forth"). Or (and) link to relevant sources, or (and)... In a certain sense, keep it as simple as possible and as complex as required while being useful in a pragmatic way.<br />
::So, now that I have rephrased the matter (hopefully in a clearer way/scope/perspective), I guess it is time for me to ask... Which is the adequate way/text/format/information that would achieve this balance <u>while reducing/stopping the "back_and_forth" editions</u>?<br />
::Reminder: the command in question is part of a section that (at the time of this writing) is named "In macOS". [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 20:18, 11 August 2019 (UTC)<br />
<br />
:::How about adding something like this:<br />
:::{{Note|The following command uses '''macOS''' ''dd''. The block size is specified differently than for GNU coreutils' ''dd''.}}<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:48, 10 February 2020 (UTC)<br />
<br />
::::I added a comment in the page source to future editors not to change it to 'M', and removed the dispute tag ('m' is absolutely correct for the default 'dd' on macOS). Hopefully this is enough. [[User:ColdPie|ColdPie]] ([[User talk:ColdPie|talk]]) 14:06, 4 May 2020 (UTC)<br />
<br />
:::::After someone reverted that, I added a note instead of an HTML comment. Hopefully instead of reverting, future editors will make improvements. [[User:ColdPie|ColdPie]] ([[User talk:ColdPie|talk]]) 13:52, 5 May 2020 (UTC)<br />
<br />
== Universal replacement for "dd" ==<br />
<br />
I've used "ddrescue" command in the past to create working media for different distributions. It has a "progress bar" built-in as well as error reporting. Should this be the default recommendation now instead of "mere dd"?<br />
<br />
{{unsigned|20:06, 28 December 2016|Beoldhin}}<br />
<br />
:The dd commands on this page include {{ic|1=status=progress}}, which shows the progress. I don't see a reason to add yet another dependency to be installed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:40, 28 December 2016 (UTC)<br />
<br />
== Add section 'Other Methods for UEFI systems' ==<br />
There's a certain amount of EFI devices that need editable(manually formatted) partitions. Such as 32-bit UEFI devices that need custom .efi files added simply in order to boot. How about adding that as a section, since we already have one for BIOS?<br />
<br />
I have included the text that I'd like to add to the article<s>(it's commented out, edit this post to see it)</s>.<br />
<br />
* Create one partition entry in GPT (of type "ef00")<br />
* Create a FAT32 filesystem on such partition replacing $LABEL with the one that corresponds to the archiso label. In case you have an archlinux-2017.03.01.iso, the label is ARCH_201703<br />
* Mount target filesystem. In this example we mount it on /mnt/esp<br />
* Extract ISO image on target filesystem.<br />
* Unmount target filesystem.<br />
<br />
# gdisk /dev/sd'''X'''<br />
# mkfs.fat -F 32 -n $LABEL /dev/sd'''Xn'''<br />
# mount /dev/sd'''Xn''' /mnt/esp<br />
# bsdtar -x --exclude=isolinux/ --exclude=EFI/archiso/ --exclude=arch/boot/syslinux/ -f archlinux-2017.03.01.iso -C /mnt/esp<br />
# umount /mnt/esp<br />
<br />
[[User:Pineman13|Pineman13]] ([[User talk:Pineman13|talk]]) 14:51, 7 January 2017 (UTC)<br />
<br />
== Using manual formatting In GNU/Linux ==<br />
<br />
Is it truth that fs on partition _must_ be FAT32? For uefi it is guaranteed to work, but for some firmware implementations it is also possible to use other fs types as I know. For legacy it could be also ext2/3/4 I guess (even syslinux is called extlinux). So I think it is better to say something like "for better compatibility" instead of "must" here.<br />
<br />
When copying files from mounted iso, maybe add exclude arguments to the command? For example, we could exclude isolinux folder.<br />
<br />
Actually, in instructions here: https://git.archlinux.org/archiso.git/tree/docs/README.transfer they mention another FSs and use excludes in extraction command. [[User:Ashark|Ashark]] ([[User talk:Ashark|talk]]) 17:47, 25 April 2019 (UTC)<br />
<br />
== dd-ed ISO to USB device + new partition for user data transfer - without failing to boot ==<br />
<br />
If for whatever reason, user does not want to use either of [[USB_flash_installation_media#Using_manual_formatting]] (because it requires FAT32 for example) or [[USB_flash_installation_media#Using_a_multiboot_USB_drive]], then here's a way to still be able boot (without failing into rescue shell) in the case when you did dd the image to the usb (via [[USB_flash_installation_media#Using_dd]]) and took the additional step to make a new partition for extra data that you wanted to have available during installation for example.<br />
<br />
Due to the way systemd identifies {{ic|1=by-label}} mounts for isohybrid ISOs (see issue in https://github.com/systemd/systemd/issues/12409 ) of which archlinux*.iso is one, you have to use kernel cmdline {{ic|1=archiso''device''=/dev/disk/by-partuuid/'''ISOUUID'''-01}} where {{ic|1=ISOUUID}} is what you get when you execute {{ic|1=blkid -p archlinux-2019.04.01-x86_64.iso}} seen in its output as {{ic|1=PTUUID="377032cf"}} (don't forget to add that {{ic|1=-01}} which means the first partition (which is the 600M iso one)), for example: {{ic|1=archisodevice=/dev/disk/by-partuuid/377032cf-01}}. For other ways to pass archisodevice to kernel cmdline, see how it's being done inside the section [[USB_flash_installation_media#Using_manual_formatting]]. Note: I've only tested grub boot (so non-UEFI) with this method and I was thus able to mount my new partition this way. Without this {{ic|1=by-partuuid}} trick, booting the iso from the USB device will fail at mounting airootfs, then if workaround it by just giving your new partition a label, it will boot ok but you won't be able to mount this new partition (details in the aforementioned systemd issue on github). [[User:Howaboutsynergy|Howaboutsynergy]] ([[User talk:Howaboutsynergy|talk]]) 22:35, 13 May 2019 (UTC)<br />
<br />
== Rufus ISO Image Mode no longer works ==<br />
<br />
From the looks of it DD Image Mode is now required. I've only tested it with UEFI. [[User:Tonij|Tonij]] ([[User talk:Tonij|talk]]) 15:15, 7 March 2020 (UTC)</div>ColdPiehttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=611064USB flash installation medium2020-05-05T13:51:28Z<p>ColdPie: /* In macOS */ Describe BSD-derived dd suffix explicitly in a note.</p>
<hr />
<div>[[Category:Installation process]]<br />
[[ar:USB flash installation media]]<br />
[[bg:USB flash installation media]]<br />
[[de:Installation von einem USB-Stick]]<br />
[[es:USB flash installation media]]<br />
[[fr:Créer une clef USB avec l'ISO Arch Linux]]<br />
[[it:USB flash installation media]]<br />
[[ja:USB インストールメディア]]<br />
[[pt:USB flash installation media]]<br />
[[ru:USB flash installation media]]<br />
[[zh-hans:USB flash installation media]]<br />
[[zh-hant:USB flash installation media]]<br />
{{Related articles start}}<br />
{{Related|CD Burning}}<br />
{{Related|Archiso}}<br />
{{Related|Multiboot USB drive}}<br />
{{Related articles end}}<br />
<br />
{{Move|USB flash installation medium|The title should use a singular form.}}<br />
<br />
This page discusses various multi-platform methods on how to create an Arch Linux Installer USB drive (also referred to as ''"flash drive", "USB stick", "USB key"'', etc) for booting in BIOS and UEFI systems. The result will be a LiveUSB (LiveCD-like) system that can be used for installing Arch Linux, system maintenance or for recovery purposes, and that, because of the nature of [[Wikipedia:SquashFS|SquashFS]], will discard all changes once the computer shuts down.<br />
<br />
If you would like to run a full install of Arch Linux from a USB drive (i.e. with persistent settings), see [[Installing Arch Linux on a USB key]]. If you would like to use your bootable Arch Linux USB stick as a rescue USB, see [[Change root]].<br />
<br />
== BIOS and UEFI bootable USB ==<br />
<br />
=== Using automatic tools ===<br />
<br />
==== In GNU/Linux ====<br />
<br />
===== Using dd =====<br />
<br />
{{Note|This method is recommended due to its simplicity. If it does not work, switch to the alternative method [[#Using manual formatting]] below.}}<br />
<br />
{{Warning|This will irrevocably destroy all data on {{ic|/dev/'''sdx'''}}. To restore the USB drive as an empty, usable storage device after using the Arch ISO image, the ISO 9660 filesystem signature needs to be removed by running {{ic|wipefs --all /dev/'''sdx'''}} as root, before [[repartition]]ing and [[reformat]]ting the USB drive.}}<br />
<br />
{{Tip|Find out the name of your USB drive with {{ic|lsblk}}. Make sure that it is '''not''' mounted.}}<br />
<br />
Run the following command, replacing {{ic|/dev/'''sdx'''}} with your drive, e.g. {{ic|/dev/sdb}}. (Do '''not''' append a partition number, so do '''not''' use something like {{ic|/dev/sdb'''1'''}})<br />
<br />
# dd bs=4M if=path/to/archlinux.iso of=/dev/'''sdx''' status=progress oflag=sync<br />
<br />
See {{man|1|dd}} for more information about [[dd]]. See {{man|1|dd|DESCRIPTION}} for more information about {{ic|1=oflag=sync}}.<br />
<br />
{{Tip|If the UEFI version of the USB's Arch ISO hangs or is unable to load, try repeating the [[dd]] medium creation process on the same USB drive one or more times.}}<br />
<br />
===== Using MultiWriter =====<br />
<br />
{{pkg|gnome-multi-writer}} is a simple gtk3 based graphical tool to write an ISO file to one or multiple USB devices at once.<br />
<br />
===== Using Kindd =====<br />
<br />
[https://github.com/LinArcX/Kindd Kindd] is a Qt based graphical frontend for dd. It is available as {{AUR|kindd}}.<br />
<br />
===== Using etcher =====<br />
<br />
[https://etcher.io/ Etcher] is a OS image flasher built with node.js and Electron, capable of flashing an SDCard or USB drive. It protects you from accidentally writing to your hard-drives and ensures every byte of data was written correctly. There are [https://aur.archlinux.org/packages/?SeB=n&K=etcher 5 related packages] in the AUR.<br />
<br />
==== In Windows ====<br />
<br />
===== Using Rufus =====<br />
<br />
[https://rufus.akeo.ie/ Rufus] is a multi-purpose USB ISO writer. It provides a graphical user interface and does not care if the drive is properly formatted or not.<br />
<br />
Simply select the Arch Linux ISO, the USB drive you want to create the bootable Arch Linux onto and click ''START''.<br />
<br />
{{Note|If the USB drive does not boot properly using the default ISO Image mode, '''DD Image mode''' should be used instead.<br />
* For Rufus version ≥ 3.0 select ''GPT'' from the ''Partition scheme'' drop-down menu. After clicking ''START'' you will get the mode selection dialog, select ''DD Image mode''.<br />
* For Rufus version < 3.0 select ''DD Image'' mode from the drop-down menu on the bottom.<br />
}}<br />
<br />
{{Tip|To add [https://github.com/pbatard/rufus/issues/691 an additional partition for persistent storage] use the slider to choose the persistent partition's size. When using the persistent partition feature, make sure to select ''MBR'' in the ''Partition scheme'' drop-down menu and ''BIOS or UEFI'' in ''Target System'', otherwise the drive will not be usable for both BIOS and UEFI booting.}}<br />
<br />
===== Using USBwriter =====<br />
<br />
This method does not require any workaround and is as straightforward as {{ic|dd}} under Linux. Just download the Arch Linux ISO, and with local administrator rights use the [https://sourceforge.net/p/usbwriter/wiki/Documentation/ USBwriter] utility to write to your USB flash memory.<br />
<br />
===== Using win32diskimager =====<br />
<br />
[https://sourceforge.net/projects/win32diskimager/ win32diskimager] is another graphical USB iso writing tool for Windows. Simply select your iso image and the target USB drive letter (you may have to format it first to assign it a drive letter), and click Write. <br />
<br />
===== Using Cygwin =====<br />
<br />
Make sure your [https://www.cygwin.com/ Cygwin] installation contains the {{ic|dd}} package.<br />
<br />
{{Tip|If you do not want to install Cygwin, you can download {{ic|dd}} for Windows from [http://www.chrysocome.net/dd here]. See the next section for more information.}}<br />
<br />
Place your image file in your home directory:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\'''x''': bs=4M<br />
<br />
where image.iso is the path to the iso image file within the {{ic|cygwin}} directory and {{ic|\\.\'''x''':}} is your USB flash drive where {{ic|'''x'''}} is the windows designated letter, e.g. {{ic|\\.\d:}}.<br />
<br />
On Cygwin 6.0, find out the correct partition with:<br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
{{Warning|This will irrevocably delete all files on your USB flash drive, so make sure you do not have any important files on the flash drive before doing this.}}<br />
<br />
dd if=image.iso of=/dev/sdb bs=4M<br />
<br />
===== dd for Windows =====<br />
<br />
A GPL licensed dd version for Windows is available at http://www.chrysocome.net/dd. The advantage of this over Cygwin is a smaller download. Use it as shown in instructions for Cygwin above.<br />
<br />
To begin, download the latest version of dd for Windows. Once downloaded, extract the archive's contents into Downloads or elsewhere.<br />
<br />
Now, launch your {{ic|command prompt}} as an administrator. Next, change directory ({{ic|cd}}) into the Downloads directory.<br />
<br />
If your Arch Linux ISO is elsewhere you may need to state the full path, for convenience you may wish to put the Arch Linux ISO into the same folder as the dd executable. The basic format of the command will look like this.<br />
<br />
# dd if=''archlinux-''version''-x86_64.iso'' od=\\.\''x'': bs=4M<br />
<br />
{{Note|The Windows drive letters are linked to a partition. To allow selecting the entire disk, ''dd for Windows'' provides the {{ic|od}} parameter, which is used in the commands above. Note however that this parameter is specific to ''dd for Windows'' and cannot be found in other implementations of ''dd''.}}<br />
<br />
{{Warning|Because the {{ic|od}} is used, all partitions on the selected disk will be destroyed. Be absolutely sure that you are directing dd to the correct drive before executing.}}<br />
<br />
Simply replace the various null spots (indicated by an "x") with the correct date and correct drive letter. Here is a complete example.<br />
<br />
# dd if=ISOs\archlinux-''version''-x86_64.iso od=\\.\d: bs=4M<br />
<br />
{{Accuracy|The following note may be invalid, the [http://www.chrysocome.net/dd upstream documentation] does not mention anything related to ''PhysicalDrive''.|section=dd for windows}}<br />
<br />
{{Note|Alternatively, replace the drive letter with {{ic|\\.\PhysicalDrive''X''}}, where {{ic|''X''}} is the physical drive number (starts from 0). Example:<br />
{{bc|1=# dd if=ISOs\archlinux-''version''-x86_64.iso of=\\.\PhysicalDrive1 bs=4M}}<br />
You can find out the physical drive number by typing {{ic|wmic diskdrive list brief}} at the command prompt or with {{ic|dd --list}}<br />
Any Explorer window must be closed or dd will report an error.}}<br />
<br />
==== In macOS ====<br />
<br />
First, you need to identify the USB device. Open {{ic|/Applications/Utilities/Terminal}} and list all storage devices with the command:<br />
<br />
$ diskutil list<br />
<br />
Your USB device will appear as something like {{ic|/dev/disk2 (external, physical)}}. Verify that this is the device you want to erase by checking its name and size and then use its identifier for the commands below instead of /dev/diskX.<br />
<br />
A USB device is normally auto-mounted in macOS, and you have to unmount (not eject) it before block-writing to it with {{ic|dd}}. In Terminal, do:<br />
<br />
$ diskutil unmountDisk /dev/diskX<br />
<br />
Now copy the ISO image file to the device. The {{ic|dd}} command is similar to its Linux counterpart, but notice the 'r' before 'disk' for raw mode which makes the transfer much faster:<br />
<br />
{{Note|BSD-derived {{ic|dd}}, which includes macOS's default {{ic|dd}}, uses lower-case {{ic|m}} suffix. This differs from GNU {{ic|dd}}, used elsewhere in this article.}}<br />
<br />
# dd if=path/to/arch.iso of=/dev/'''r'''diskX bs=1m<br />
<br />
This command will run silently. To view progress, send SIGINFO by pressing {{ic|Ctrl+t}}. Note {{ic|diskX}} here should not include the {{ic|s1}} suffix, or else the USB device will only be bootable in UEFI mode and not legacy. After completion, macOS may complain that "The disk you inserted was not readable by this computer". Select 'Ignore'. The USB device will be bootable.<br />
<br />
==== In Android ====<br />
<br />
===== EtchDroid =====<br />
<br />
[https://etchdroid.depau.eu/ EtchDroid] is a OS image flasher for Android. It works without root permissions on Android 5 to Android 8. According to bug reports it doesn't always work on Android 9 and Android 4.4.<br />
<br />
To create an Arch Linux installer, download the ISO image file on your Android device. Plug the USB drive to your device, using a USB-OTG adapter if needed. Open EtchDroid, select "Flash raw image", select your Arch ISO, then select your USB drive. Grant the USB API permission and confirm.<br />
<br />
Keep your phone on a table while it's writing the image: a lot of USB-OTG adapters are a bit wobbly and you might unplug it by mistake.<br />
<br />
=== Using manual formatting===<br />
<br />
==== In GNU/Linux ====<br />
<br />
This method is more complicated than writing the image directly with {{ic|dd}}, but it does keep the flash drive usable for data storage (that is, the ISO is installed in a specific partition within the already [[Partitioning|partitioned device]] without altering other partitions).<br />
<br />
{{Note|Here, we will denote the targeted partition as {{ic|/dev/sd'''Xn'''}}. In any of the following commands, adjust '''X''' and '''n''' according to your system.}}<br />
<br />
* If not done yet, create a [[partition table]] on {{ic|/dev/sd'''X'''}}.<br />
* If not done yet, create a partition on the device. The partition {{ic|/dev/sd'''Xn'''}} must be formatted to [[FAT32]].<br />
* Mount the ISO image, mount the FAT32 filesystem located in the USB flash device, and copy the contents of the ISO image to it. Then unmount the ISO image, but keep the FAT32 partition mounted (this may be used in subsequent steps). For example:<br />
<br />
# mkdir -p /mnt/{iso,usb}<br />
# mount -o loop archlinux-''version''-x86_64.iso /mnt/iso<br />
# mount /dev/sd'''Xn''' /mnt/usb<br />
# cp -a /mnt/iso/* /mnt/usb<br />
# sync<br />
# umount /mnt/iso<br />
<br />
To boot either a label or an [[UUID]] to select the partition to boot from is required. By default the label {{ic|ARCH_''YYYYMM''}} (with the appropriate release year and month) is used. Thus, the [[Persistent block device naming#by-label|file system’s label]] has to be set accordingly, for example using ''gparted''. Alternatively, you can change this behaviour by altering the lines ending by {{ic|1=archisolabel=ARCH_''YYYYMM''}} in the file {{ic|/mnt/usb/arch/boot/syslinux/archiso_sys.cfg}} (for BIOS boot), and in {{ic|/mnt/usb/loader/entries/archiso-x86_64.conf}} (for UEFI boot). To use an UUID instead, replace those portions of lines with {{ic|1=archiso''device''=/dev/disk/by-uuid/'''YOUR-UUID'''}}. The UUID can be retrieved with {{ic|1=blkid -o value -s UUID /dev/sd'''Xn'''}}.<br />
<br />
{{Warning|Mismatching labels or wrong UUID prevents booting from the created medium.}}<br />
<br />
Syslinux files for BIOS systems are already copied to {{ic|/mnt/usb/arch/boot/syslinux}}. Install the {{Pkg|syslinux}} package and follow [[Syslinux#Manual install]] instructions to make the partition bootable.<br />
<br />
==== In Windows ====<br />
<br />
{{Note|<br />
* For manual formatting, do not use any '''Bootable USB Creator utility''' for creating the UEFI bootable USB. For manual formatting, do not use ''dd for Windows'' to dd the ISO to the USB drive either.<br />
* In the below commands, '''X:''' is assumed to be the USB flash drive in Windows.<br />
* Windows uses backward slash {{ic|\}} as path-separator, so the same is used in the below commands.<br />
* All commands should be run in Windows command prompt '''as administrator'''.<br />
* {{ic|>}} denotes the Windows command prompt.<br />
}}<br />
<br />
* Partition and format the USB drive using [https://rufus.akeo.ie/ Rufus USB partitioner]. Select partition scheme option as '''MBR for BIOS and UEFI''' and File system as '''FAT32'''. Uncheck "Create a bootable disk using ISO image" and "Create extended label and icon files" options.<br />
* Change the '''Volume Label''' of the USB flash drive {{ic|X:}} to match the LABEL mentioned in the {{ic|1=archisolabel=}} part in {{ic|<ISO>\loader\entries\archiso-x86_64.conf}}. This step is required for Official ISO ([[Archiso]]). This step can be also performed using Rufus, during the prior "partition and format" step.<br />
* Extract the ISO (similar to extracting ZIP archive) to the USB flash drive using [https://www.7-zip.org/ 7-Zip]. <br />
* Download official Syslinux 6.xx binaries (zip file) from https://www.kernel.org/pub/linux/utils/boot/syslinux/ and extract it. The version of Syslinux should be the same version used in the ISO image.<br />
<br />
* Run the following command (in Windows cmd prompt, as admin):<br />
<br />
> cd bios\<br />
> for /r %Y in (*.c32) do copy "%Y" "X:\arch\boot\syslinux\" /y<br />
> copy mbr\*.bin X:\arch\boot\syslinux\ /y<br />
<br />
* Install Syslinux to the USB by running (use {{ic|win64\syslinux64.exe}} for x64 Windows):<br />
<br />
> cd bios\<br />
> win32\syslinux.exe -d /arch/boot/syslinux -i -a -m X:<br />
<br />
{{Note|<br />
* The above step installs Syslinux's {{ic|ldlinux.sys}} to the VBR of the USB partition, sets the partition as "active/boot" in the MBR partition table and writes the MBR boot code to the 1st 440-byte boot code region of the USB.<br />
* The {{ic|-d}} switch expects a path with forward slash path-separator like in *unix systems.<br />
}}<br />
<br />
== Other methods for BIOS systems ==<br />
<br />
=== In GNU/Linux ===<br />
<br />
==== Using a multiboot USB drive ====<br />
<br />
This allows booting multiple ISOs from a single USB device, including the archiso. Updating an existing USB drive to a more recent ISO is simpler than for most other methods. See [[Multiboot USB drive]].<br />
<br />
==== Using GNOME Disk Utility ====<br />
<br />
Linux distributions running GNOME can easily make a live CD through {{Pkg|nautilus}} and {{Pkg|gnome-disk-utility}}. Simply right-click on the ''.iso'' file, and select ''Open With Disk Image Writer''. When GNOME Disk Utility opens, specify the flash drive from the ''Destination'' drop-down menu and click ''Start Restoring''.<br />
<br />
==== Making a USB-ZIP drive ====<br />
<br />
For some old BIOS systems, only booting from USB-ZIP drives is supported. This method allows you to still boot from a USB-HDD drive.<br />
<br />
{{Warning|This will destroy all information on your USB flash drive!}}<br />
<br />
* Download {{Pkg|syslinux}} and {{Pkg|mtools}} from the official repositories.<br />
* Find your usb drive with {{ic|lsblk}}.<br />
* Type {{ic|mkdiskimage -4 /dev/sd'''x''' 0 64 32}} (replace x with the letter of your drive). This will take a while.<br />
<br />
From here continue with the manual formatting method. The partition will be {{ic|/dev/sd'''x'''4}} due to the way ZIP drives work.<br />
<br />
{{Note|Do not format the drive as FAT32; keep it as FAT16.}}<br />
<br />
==== Using UNetbootin ====<br />
<br />
UNetbootin can be used on any Linux distribution or Windows to copy your iso to a USB device. However, Unetbootin overwrites {{ic|syslinux.cfg}}, so it creates a USB device that does not boot properly. For this reason, '''Unetbootin is not recommended''' -- please use {{ic|dd}} or one of the other methods discussed in this topic.<br />
<br />
{{Warning|UNetbootin writes over the default {{ic|syslinux.cfg}}; this must be restored before the USB device will boot properly.}}<br />
<br />
Edit {{ic|syslinux.cfg}}:<br />
<br />
{{hc|sysconfig.cfg|2=<br />
default menu.c32<br />
prompt 0<br />
menu title Archlinux Installer<br />
timeout 100<br />
<br />
label unetbootindefault<br />
menu label Archlinux_x86_64<br />
kernel /arch/boot/x86_64/vmlinuz<br />
append initrd=/arch/boot/x86_64/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
}}<br />
<br />
In {{ic|/dev/sd'''x1'''}} you must replace '''x''' with the first free letter after the last letter in use on the system where you are installing Arch Linux (e.g. if you have two hard drives, use {{ic|c}}.). You can make this change during the first phase of boot by pressing {{ic|Tab}} when the menu is shown.<br />
<br />
=== In Windows ===<br />
<br />
==== The Flashnul way ====<br />
<br />
[https://translate.google.com/translate?hl=&sl=ru&tl=en&u=http%3A%2F%2Fshounen.ru%2Fsoft%2Fflashnul%2Freadme.rus.html&sandbox=1 flashnul] is an utility to verify the functionality and maintenance of Flash-Memory (USB-Flash, IDE-Flash, SecureDigital, MMC, MemoryStick, SmartMedia, XD, CompactFlash etc).<br />
<br />
From a command prompt, invoke flashnul with {{ic|-p}}, and determine which device index is your USB drive, e.g.:<br />
<br />
{{hc|C:\>flashnul -p|<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
}}<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, {{ic|-L}}, and the path to your image, e.g:<br />
<br />
C:\>flashnul '''E:''' -L ''path\to\arch.iso''<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
{{Note|Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64.}}<br />
<br />
==== Loading the installation medium from RAM ====<br />
<br />
{{Merge|Multiboot USB drive#Using Syslinux and memdisk|This is the same method, only Syslinux is installed from Windows. Considering that [[multiboot USB drive]] can be used to boot an installation medium and it is already linked from the Related articles box at the top, maybe this section should be merged there?}}<br />
<br />
This method uses [[Syslinux]] and a [[Ramdisk]] ([https://wiki.syslinux.org/wiki/index.php/MEMDISK MEMDISK]) to load the entire Arch Linux ISO image into RAM. Since this will be running entirely from system memory, you will need to make sure the system you will be installing this on has an adequate amount. A minimum amount of RAM between 500 MB and 1 GB should suffice for a MEMDISK based, Arch Linux install.<br />
<br />
For more information on Arch Linux system requirements as well as those for MEMDISK see the [[Installation guide]] and [http://www.etherboot.org/wiki/bootingmemdisk#preliminaries here]. For reference, here is the [https://bbs.archlinux.org/viewtopic.php?id=135266 preceding forum thread].<br />
<br />
{{Tip|Once the installer has completed loading you can simply remove the USB stick and even use it on a different machine to start the process all over again. Utilizing MEMDISK also allows booting and installing Arch Linux to and from the same USB flash drive.}}<br />
<br />
===== Preparing the USB flash drive =====<br />
<br />
Begin by formatting the USB flash drive as '''FAT32'''. Then create the following folders on the newly formatted drive.<br />
<br />
* {{ic|Boot}}<br />
** {{ic|Boot/ISOs}}<br />
** {{ic|Boot/Settings}}<br />
<br />
===== Copy the needed files to the USB flash drive =====<br />
<br />
Next copy the ISO that you would like to boot to the {{ic|Boot/ISOs}} folder. After that, extract from the following files from the latest release of {{pkg|syslinux}} from [https://www.kernel.org/pub/linux/utils/boot/syslinux/ here] and copy them into the following folders.<br />
* {{ic|./win32/syslinux.exe}} to the Desktop or Downloads folder on your system.<br />
* {{ic|./memdisk/memdisk}} to the {{ic|Settings}} folder on your USB flash drive.<br />
<br />
===== Create the configuration file =====<br />
<br />
After copying the needed files, navigate to the USB flash drive, /boot/Settings and create a {{ic|syslinux.cfg}} file.<br />
<br />
{{Warning|On the {{ic|INITRD}} line, be sure to use the name of the ISO file that you copied to your {{ic|ISOs}} folder.}}<br />
<br />
{{hc|/Boot/Settings/syslinux.cfg|2=<br />
DEFAULT arch_iso<br />
<br />
LABEL arch_iso<br />
MENU LABEL Arch Setup<br />
LINUX memdisk<br />
INITRD /Boot/ISOs/archlinux-''version''-x86_64.iso<br />
APPEND iso<br />
}}<br />
<br />
For more information on Syslinux see the [[Syslinux|Arch Wiki article]].<br />
<br />
===== Final steps =====<br />
<br />
Finally, create a {{ic|*.bat}} file where {{ic|syslinux.exe}} is located and run it ("Run as administrator" if you are on Vista or Windows 7):<br />
<br />
{{hc|C:\Documents and Settings\username\Desktop\install.bat|<br />
@echo off<br />
syslinux.exe -m -a -d /Boot/Settings X:<br />
}}<br />
<br />
== Troubleshooting ==<br />
<br />
* If you get the "device did not show up after 30 seconds" error due to the {{ic|/dev/disk/by-label/ARCH_''YYYYMM''}} not mounting, try renaming your USB medium to {{ic|ARCH_''YYYYMM''}} (e.g. {{ic|ARCH_201501}}).<br />
* If you get errors, try using another USB device. There are case scenarios in which it solved all issues.<br />
<br />
== See also ==<br />
<br />
* [https://wiki.gentoo.org/wiki/LiveUSB/HOWTO Gentoo wiki - LiveUSB/HOWTO]<br />
* [https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB Fedora wiki - How to create and use Live USB]<br />
* [https://en.opensuse.org/SDB:Live_USB_stick openSUSE wiki - SDB:Live USB stick]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Talk:USB_flash_installation_medium&diff=610829Talk:USB flash installation medium2020-05-04T14:07:02Z<p>ColdPie: /* Repeated editions, back and forth */</p>
<hr />
<div>== About making the installation media without overwriting ==<br />
<br />
I'm not totally sure if I misunderstood something, but I had to change the path of the entries of the *.cfg files. For instance:<br />
<br />
INCLUDE boot/syslinux/archiso_sys.cfg<br />
<br />
became:<br />
<br />
INCLUDE syslinux/archiso_sys.cfg<br />
<br />
It was the only way it worked with the unofficial ISO x86_64 image of march 13th, 2012. Looks like the syslinux command described in the page doesn't get the path as it should. <br />
<br />
I edited all of the .cfg files, but probably only editing this ones should have been enough:<br />
<br />
archiso.cfg<br />
archiso_head.cfg<br />
archiso_sys_inc.cfg<br />
<br />
I hope it could be useful to somebody, because I spend some time with this (I even thought that was a problem with the hardware). I think it could be possible to make a simple script (or give some command lines) to patch the files once they are copied into the USB and run syslinux.<br />
<br />
Thanks !!<br />
:I cannot find that this is still relevant to the article as it now exists. I am striking it out as it looks like it could be good to remove. [[User:AdamT|AdamT]] ([[User talk:AdamT|talk]]) 10:33, 8 August 2013 (UTC)<br />
<br />
::Just lunched from USB drive without UUID(don't have any idea why it didn't have one). Solution was to change label to appropriate in loader/entries/archiso-x86_64.conf. Not sure weither this should be added to article.<br />
--[[User:Versusvoid|Versusvoid]] ([[User talk:Versusvoid|talk]]) 16:00, 18 August 2013 (UTC)<br />
::Versusvoid, I would love to adapt the article but I cannot follow your description above. Looking at that section, it may be out dated. If you are watching this please elaborate when you have time. Thanks, [[User:AdamT|AdamT]] ([[User_talk:AdamT|Talk]]) 08:32, 23 August 2013 (UTC)<br />
<br />
:::Ok. For some reason ubuntu did not see USB UUID. So ''blkid -o value -s UUID /dev/sdx1'' were returning empty string. The solution was:<br />
<br />
:::''$ sed -i "s|label=ARCH_.*|label=$(blkid -o value -s LABEL /dev/sdx1)|" loader/entries/archiso-x86_64.conf''<br />
<br />
:::in the USB mounting directory. --[[User:Versusvoid|Versusvoid]] ([[User talk:Versusvoid|talk]]) 08:05, 31 August 2013 (UTC)<br />
<br />
:::It seems that sometimes you have to get the UUID by running the command as root. --[[User:Rongmu|Rongmu]] ([[User talk:Rongmu|talk]]) 11:23, 3 October 2013 (UTC)<br />
::::Thank you for the follow-up. My semester started so I have not had much of a chance to help with the Arch Wiki of late. I am removing the strike from this section until I can take a closer look and update the article. [[User:AdamT|AdamT]] ([[User_talk:AdamT|Talk]]) 02:02, 16 November 2013 (UTC)<br />
<br />
== Making an UEFI/BIOS ISO should be KISS ==<br />
<br />
Following up on the discussion in the [https://bbs.archlinux.org/viewtopic.php?id=173559 the bbs], I disagree that [https://wiki.archlinux.org/index.php?title=Talk:USB_Flash_Installation_Media&oldid=284705 this edit] should be kept as the first thing users see when hitting this page. I based this opinion on my feeling that the instructions are too many steps and, arguably too vague. Example, this method is 7 steps (depending on how you count) and requires that user read linked articles (i.e syslinux install and modifying master boot records). In contrast, the dd method is simple (KISS principal) and is both [https://projects.archlinux.org/archiso.git/commit/?id=f19f6173c8650ebc43dc166ee2a2f3f92a753afe implemented] and [https://projects.archlinux.org/archiso.git/commit/?id=ce9c853292e0d37e3931634f43ce697ccd33ad11 documented] as pointed out by one of our developers in the aforementioned bbs thread.<br />
<br />
I think we should at least start the article with the KISS method and this edit down the page. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 10:30, 29 November 2013 (UTC)<br />
<br />
: Well, I have been keeping an eye on this since the.ridikulus.rat's extensive edits on and after 2013-11-20. I have kept quiet because the maintainers and admins seemed to accept the changes. However, from the start, I disagreed along lines similar to what Graysky has mentioned above.<br />
<br />
: I did not, and do not, understand why the Arch Wiki should be recommending a specific method without any references or firm reasoning. Instead the.ridikulus.rat seemed to be prescribing a method that was believed was superior based on their own preferences. ''This method is slightly more complicated than writing the image directly with {{ic|dd}}, but it does keep the drive usable for data storage.''<br />
<br />
: <s>Please note this quote from the [https://bbs.archlinux.org/viewtopic.php?pid=1354844#p1354844 BBS thread] Graysky linked above (emphasis mine): ''It took me some time to read through the syslinux docs and other blog [sic] to understand the syslinux installation process under Windows, and '''I don't appreciate you simply removing the entire part that I thought out and typed for the sake of the community.'''''</s> I just realized I completely mistook what the.ridikulus.rat meant to say here. Please disregard.<br />
<br />
: While I do think the technical information that the.ridikulus.rat provided was needed in general, and I had in fact [[Talk:Unified_Extensible_Firmware_Interface#Migrate_UEFI_Bootable_Media_to_USB_Flash_Installation_Media.3F|proposed something similar]] shortly before, the extensive reordering of the page and the subjective recommendations does not seem in keeping with the [[ArchWiki:About|ideals]] and [[Help:Editing|established processes]] of the Arch Wiki as I understand them. <br />
<br />
: <s>Further, referencing the quote above, egos definitely seem to be coming into play in a place where they should not matter. The sake of the community is what matters here, not individual investments. See also [[The Arch Way]].</s><br />
<br />
: Moving forward, as of this writing, the changes that Teateawhy has been making seem to be in keeping with the practices put forth in the Arch Wiki's documentation while also mitigating the subjective recommendation that was put forth during the.ridikulus.rat's changes.<br />
<br />
: As a fairly new contributor, one aspect I have not been able to determine from reading over the Arch Wiki's documentation is when and how to make recommendations. As such, and keeping an eye on the bigger picture here, I would like to take this opportunity to suggest something be added to [[Help:Style]] or elsewhere regarding when and how recommendations and suggestions are justified. There seems to be a willingness for some contributors to make claims without references or supporting statements. Similar to Wikipedia's "reference needed" template, a flag or at least cohesive policy may be warranted for the Arch Wiki and it may help prevent situations like this in the future! : )<br />
<br />
: Cheers all, [[User:AdamT|AdamT]] ([[User_talk:AdamT|Talk]]) 03:17, 30 November 2013 (UTC)<br />
<br />
: I agree that dd is the easiest method, but I would like to use the manual method in order to use a USB drive also as data storage. I'm not new to Linux by a long shot, but the text is so garbled up that I can't successfully follow the manual method... [[User:Jrg2718]], 07 May 2014<br />
<br />
=== Side notes ===<br />
<br />
I don't want to hijack the main discussion, but I'd like to answer a couple of AdamT's observations:<br />
<br />
* please do not assume that admins and maintainers can follow everything that happens on the wiki; if you have something to say about somebody else's edits just do it ;)<br />
* I'd be glad to add some guidelines about recommendations to the style guide; the problem is that it's still very subjective to distinguish between what is a ''justified'' recommendation and what is a ''personal'' recommendation... Technically The.ridikulus.rat did justify his suggestion. If you have an idea for the wording of an effective style guide, please propose it here or in [[Help talk:Style]], but I think that most of these cases will have to be solved in discussion pages like it's happened here.<br />
<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 01:34, 1 December 2013 (UTC)<br />
<br />
== Other Methods for BIOS systems ==<br />
<br />
Do we really need these provided that dd just works? I suggest deletion of them as outdated. [[User:SkyBon|SkyBon]] ([[User talk:SkyBon|talk]]) 15:12, 28 January 2014 (UTC)<br />
<br />
:Are they outdated, i.e. you're sure they don't work? Otherwise I don't see the reason to delete them, we let users choose their preferred method. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:55, 29 January 2014 (UTC)<br />
<br />
== Graphical dd methods for Linux and Windows ==<br />
<br />
Hi from Fedoraland, Arch folks! I just finished updating the [https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB Fedora wiki page for doing USB writing] - with some references from the rather good SUSE pages on the same topic - [http://en.opensuse.org/SDB:Live_USB_stick main page], [http://en.opensuse.org/SDB:Create_a_Live_USB_stick_using_Windows Windows], [http://en.opensuse.org/SDB:Create_a_Live_USB_stick_using_Mac_OS_x OS X]. I think Arch, Fedora and SUSE all prefer a 'dd' style writing method, so we can take cues from each other here. The Fedora and SUSE pages both now feature ways to do a dd-style write on Windows and OS X, and the Fedora page has a rather convenient method for doing a dd-style write from GNOME - perhaps Arch might like to pick these up too? Could be handy for your users. I tested the recommended Windows tools (SUSE's Studio writer, and rawrite32) on a Windows laptop, and they both clearly did a clean direct write of the image, with Fedora's complex disk label setup to ensure BIOS, UEFI and Mac boot all work kept intact. i.e., they don't screw crap up like unetbootin or that Ubuntu tool does.<br />
<br />
I suppose we could even think about providing a unified set of instructions / tools somewhere - there's quite a bit of redundancy going on at the moment. Thanks! [[User:AdamW|AdamW]] ([[User talk:AdamW|talk]]) 19:06, 30 January 2014 (UTC)<br />
<br />
:Hi AdamW, thank you for your work and for trying to involve our community! For the moment I've referenced the Fedora and openSUSE articles from our See also section, however let's keep this discussion open to see if somebody wants to adapt the methods we're missing for Arch on this article. We may even add some Expansion templates where needed, as reminders and to encourage contributions. In alternative, since in general instead of duplicating external sources we prefer to just provide links to them if they're well maintained, we may just add more specific links to the Fedora article in the proper sections.<br />
:Of course it would be great if we managed to reduce the redundancy among our articles with a unified article "somewhere", but the problem would be how to make it easy for our respective wiki users to edit such article without forcing them to register on another wiki (which clearly would instead have the effect of discouraging contributions). Maybe we could keep part of our articles synchronized with a bot?<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:25, 1 February 2014 (UTC)<br />
<br />
== dd for windows ==<br />
\\.\ notation is a Microsoft construct. It addresses a device in the DOS namespace. The documentation is here:<br />
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx<br />
<br />
\\? is a dd construct. It means address a device in the NT native namespace.<br />
<br />
Not all devices are available in the DOS namespace and the rules vary between OS versions and partition type codes etc.<br />
[[User:Jnewbigin|Jnewbigin]] ([[User talk:Jnewbigin|talk]]) 01:32, 12 December 2014 (UTC)<br />
<br />
:I tested the \\.\ notation with Windows 10 1607 (OS Build 14393.222) and cygwin but it did not work. Instead I used /dev/sdx and it worked perfect. [[User:Hncr|Hncr]] ([[User talk:Hncr|talk]]) 23:30, 13 October 2016 (UTC)<br />
<br />
== Using Universal USB Installer ==<br />
<br />
This bit of advice doesn't currently work. The media creates fine but when you try to boot, you get exactly into [https://bbs.archlinux.org/viewtopic.php?pid=1344629 this story]. [[User:All3fox|All3fox]] ([[User talk:All3fox|talk]]) 07:41, 13 April 2014 (UTC)<br />
<br />
:The problem and bbs thread with explanation is referenced in [[USB Flash Installation Media#Using Universal USB Installer]] meanwhile. Closing this. Thanks for reporting! --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:55, 16 August 2014 (UTC)<br />
<br />
::Re-opening, wrt the following edition(s) https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&diff=335781&oldid=335762 .<br />
<br />
::I am confused by this specific edition(s). AFAIK, and at least at the time I am writing this (2014Sep), UUI does not support booting on UEFI systems. To be clear, I mean that UUI is aimed to prepare a USB flash drive to initially boot by means of Syslinux under BIOS (with the caveats already mentioned in the wiki article), and UUI does not know how to boot/use syslinux.efi (nor any other UEFI bootloader). Am I misinformed?<br />
<br />
::I am not saying that a USB flash drive, after using UUI, is incapable of booting UEFI hardware, but it is not UUI that makes it happen. So mentioning UEFI in a Note about UUI is slightly confusing (to me).<br />
<br />
::I don't want to undo the editions before I am sure I am not misunderstanding something. So, am I? [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 22:11, 16 September 2014 (UTC)<br />
<br />
:::I wrote the UUI section and came here to ask the same question: this section is about making an Arch boot USB using windows, and is not specific to EFI-bootable USB disks. The goal is just to bootstrap Arch on the system. Once Arch is booted you can set up your permanent storage to boot any way you like. In particular, I have used a UUI-created boot disk to set up a UEFI system many times. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 11:05, 5 January 2015 (UTC)<br />
<br />
:: To test, I used UUI to create a ARCH_201501 USB boot disk, and then proceeded to use it to EFI boot and install a new server. I'm going to remove the Inaccurate warning, since it is itself inaccurate.<br />
<br />
== Syslinux note ==<br />
<br />
-- ''Moved from [[Help:Style]], as the discussion shifted back to this article.'' -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:46, 22 September 2014 (UTC)<br />
<br />
@Ady (reopening): first of all I want to make clear that I didn't write the "own[ing]" argument in an accusing way, it was only meant to explain my point of view, I should have added a smiley at the end, I'll do it now :)<br />
More important, you said we "derail[ed] from the initial goal", but actually I asked you some questions that were very relevant and specific to your edit, and you haven't answered, so I'll paste them here again:<br />
Where exactly is that note inaccurate? Because usually when you feel some deeper explanations are out of place in some article it's because that article's topic is quite different, so the details should belong somewhere else: is it something regarding [[syslinux]]? Because we have an entire article for it, maybe you could add what's needed there and simply link there from the note?<br />
-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:49, 17 August 2014 (UTC)<br />
<br />
:@Kynikos, Since the discussion was moved, the focus changed from the more-technical matter to whether using hidden text was/is appropriate (in this particular case). Thus, I thought that perhaps answering those questions here would have been considered off-topic.<br />
<br />
:The referenced Note says "''The above step installs Syslinux's ldlinux.sys to the VBR of the USB partition, sets the partition as "active/boot" in the MBR partition table and writes the MBR boot code to the 1st 440-byte boot code region of the USB.''". As you can see, this Note is not part of a practical step (and therefore, a slight inaccuracy is likely not going to affect a typical reader following the instructions). Yet, there is a purpose for this Note.<br />
<br />
:Users kept asking (including to upstream Syslinux) whether they can skip part of the steps, and just copy over ldlinux.sys (for example, to either install or update SYSLINUX in their USB drives). Moreover, some users didn't even ask; they simply (over)wrote this file and they complained that SYSLINUX (and/or Arch) fails to boot. So the Note is there to prevent this type of behavior / confusion / repeated waste of time. This explains why deleting the referenced Note would not be wise.<br />
<br />
:About the minor inaccuracy... What the SYSLINUX installer does (when performing the specific steps exactly as described in the relevant section of the article) is to:<br />
:* copy ldlinux.{sys,c32};<br />
:* patch the VBR so it can point to the correct block in the device (so ldlinux.sys can be found);<br />
:* set the partition as "active/boot" in the partition table;<br />
:* write the MBR boot code to the 1st 440-byte boot code region of the USB.<br />
<br />
:I want to clarify that the above description is only relevant for the specific section we are referring to. The SYSLINUX/EXTLINUX installers perform different tasks according to different cases.<br />
<br />
:So, there is a minor (technical) background inaccuracy in the Note.<br />
<br />
:Considering the goal of this Note (as I already described it above) in the context of this particular section of this particular article, and considering that the practical steps provided in the article are not affected by this minor inaccuracy, I asked my self (at the time I performed other editions on the article) whether I should also edit the Note. Would I be actually helping a typical reader that is interested in following the steps? With the objective to balance between accuracy and clarity for the typical reader, I decided not to over-complicate the Note with excessive details that in practical terms only would make the section longer without improving the outcome.<br />
<br />
:Adding a link to the [[Syslinux]] article would not improve the practical experience / steps for the user in this case. If anyone wants to find more technical information, they don't need yet another link from that same article to the same Syslinux page. In this article, the typical reader is (and/or should better be) likely focused on the practical steps.<br />
<br />
:Thus, my "hint" was "''This note is not %100 technically accurate, but it is "accurate-enough" so to be able to perform the task.''". For the typical reader trying to follow the practical steps, the procedure is accurate and he will complete the task successfully, so adding an "Accuracy" box would be counterproductive.<br />
<br />
:Generally speaking, I think there are cases where adding 'comments' (aka hidden text) is adequate, but I am perfectly fine following the guidelines in [[Help:Style]]. Lahwaacz's edition formatted the "hint" as "Accuracy" box, going exactly in the opposite direction of what the hint itself was saying (or at least, against the original intention of the comment). This was not beneficial for users, so I deleted the box.<br />
<br />
:Slightly long to read (apologies), but I hope this clarifies the matter. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 10:45, 17 August 2014 (UTC)<br />
<br />
::I see, thanks for explaining, then why not make explicit the reason why the note is there (KISS), like:<br />
::{{Note|<br />
::* Make sure to run the above command in full, which installs Syslinux's {{ic|ldlinux.sys}} to the VBR of the USB partition, sets the partition as "active/boot" in the MBR partition table and writes the MBR boot code to the 1st 440-byte boot code region of the USB. Only copying the file, for example in an attempt to update an existing Syslinux installation, will result in an unbootable device.<br />
::* ...}}<br />
::This way nobody will see the note as useless and delete it.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:50, 19 August 2014 (UTC)<br />
<br />
== "... and install the MBR or GPT partition table to the USB device as described in the page mentioned." ==<br />
<br />
I am somewhat clueless about what page this instruction in [[USB_flash_installation_media#Using_manual_formatting]] is referring to, can anyone clear that up, what is "the page mentioned"? There is no further mentioning of GPT in the article. Also, not clear why it should be necessary to create a partition table on a USB device, which obviously is partitioned already (else, I wouldn't be able to manipulate any files on it). --[[User:Johannes Rohr|Johannes Rohr]] ([[User talk:Johannes Rohr|talk]]) 08:40, 5 February 2015 (UTC)<br />
<br />
:The previous link leads to [[Syslinux#Manual_install]], have you looked there? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:46, 5 February 2015 (UTC)<br />
<br />
::''Also, not clear why it should be necessary to create a partition table on a USB device, which obviously is partitioned already''<br />
<br />
:I think this has to do with UEFI vs. BIOS booting. In the case of the more modern UEFI, you have a special FAT32-formatted boot partition which is labeled EF00 (so there are 2 partitions on the disk). If you're just going to create a BIOS boot USB, then you only need a single partition. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 09:44, 5 February 2015 (UTC)<br />
<br />
== Repeated editions, back and forth ==<br />
<br />
Is there any way to provide the "adequate" commands for each relevant case, so as to avoid these back_and_forth editions?<br />
<br />
[https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&diff=452196&oldid=450793] [https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&diff=423359&oldid=421431] [https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&diff=418452&oldid=416855]<br />
<br />
[[User:Ady|Ady]] ([[User talk:Ady|talk]]) 16:08, 27 September 2016 (UTC)<br />
<br />
:And [https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&curid=2331&diff=453974&oldid=452196 here] we go, again. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 05:20, 15 October 2016 (UTC)<br />
<br />
::I see 4 options here:<br />
:::1. Ban the users in question for edit warring instead of using the talk page, or temporarily lock the page<br />
:::2. Remove the section and link to some OS X resource instead<br />
:::3. Use a different tool like ''cat''<br />
:::4. Mention that you might have to use 1M if 1m doesn't work, or vice-versa.<br />
::I'm inclined to go with 2.<br />
::-- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:28, 15 October 2016 (UTC)<br />
<br />
:::Even before I started this Talk section, I already thought I would go with your option 4. I think it should stop the "back and forth", it would be a simple, short and clear addition to the current text, it would respect users that have invested their time to add the whole set of instructions, and the general steps in the section would remain valid, without depending on third-party sites / sources. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 09:53, 15 October 2016 (UTC)<br />
<br />
::[[User:Almax|Almax]] ([[User talk:Almax|talk]]) 12:23, 15 October 2016 (UTC)<br />
:::Guilty as charged. My guess for why back and forth is happening: Linux folks change the block size multiplier to uppercase M when they see it in the wiki (correct syntax for Linux dd) and Mac folks change it to lowercase m (correct syntax for Mac OS/BSD dd; only accepts b, k, m, g, w). The only correct edit for Mac OS is lowercase m, but how to prevent well-meant "corrections"? I support option 4-ish: Add a Note: explicitly explaining that the args are different between the systems and/or explain it when showing the actual dd command. I arrogantly rewrote the whole section yesterday because I found it to be oddly worded, containing redundant steps and not including info about the device's file system not being recognized by Mac OS after writing the arch*.iso to it. I hope the edit is acceptable. I'm new in the Arch community but no newcomer to Macs or Linux.<br />
<br />
<br />
::::Part of the problem is that some users would "extend" certain concepts and/or commands from one OS to another, but other users would interpret this extension differently, or even perform it differently.<br />
<br />
::::For instance, some users would assume that some command in Linux can be executed exactly the same in BSD, with the same expectations / results. Others might assume the same behavior when going from Mac OS X (or whichever similar name would be valid/current at each time) to BSD.<br />
<br />
::::For example, [[User:Agentxp22]] performed at least one of these editions (I re-post here the link for convenience), [https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&diff=418452&oldid=416855] with a summary note:<br />
<blockquote><br />
1m > 1M because BSD dd uses upper case M for MB block size<br />
</blockquote><br />
<br />
::::I am not getting into the matter of which command is correct (and which is not) for each OS. This Talk section is not about that.<br />
<br />
::::I think we should not "fight" such assumptions, because (too) many users have them, and "policing" each edition (not just in one article) is time-consuming and prone to mistakes. Instead, IMO a more practical solution is to just add a relevant minimal paragraph/sentence/note, as suggested by the 4rth alternative solution proposed by Alad, at least in this particular case.<br />
<br />
::::As I said, it should stop the "back and forth" editions, and clarify the procedure/command while avoiding assumptions. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 14:55, 15 October 2016 (UTC)<br />
<br />
And now we have [https://wiki.archlinux.org/index.php?title=USB_flash_installation_media&diff=579124&oldid=578856]. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 15:00, 8 August 2019 (UTC)<br />
<br />
:If no one can find out the correct unit specification for macOS, just remove the {{ic|bs}} parameter entirely and let the macOS users write 512 bytes at a time. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]])<br />
<br />
<br />
:[[User:Ady|Ady]], that was me and now I realize which version of ''dd'' I used, the GNU one. We should use the syntax for the ''default'' version that comes with macOS, which is the FreeBSD version, and optionally add a comment to specify for those that use the [https://www.gnu.org/software/coreutils/coreutils.html coreutils] version. <br />
:From the [https://linux.die.net/man/1/dd GNU man page]:<br />
<br />
BLOCKS and BYTES may be followed by the following multiplicative suffixes: c<br />
=1, w =2, b =512, kB =1000, K =1024, MB =1000*1000, M =1024*1024, xM =M GB<br />
=1000*1000*1000, G =1024*1024*1024, and so on for T, P, E, Z, Y. <br />
<br />
:From the [https://www.freebsd.org/cgi/man.cgi?query=dd&apropos=0&sektion=0&manpath=FreeBSD+12.0-RELEASE+and+Ports&arch=default&format=html FreeBSD man page]:<br />
<br />
Where sizes or speed are specified, a decimal, octal, or hexadecimal num-<br />
ber of bytes is expected. If the number ends with a ``b'', ``k'', ``m'',<br />
``g'', ``t'', ``p'', or ``w'', the number is multiplied by 512, 1024<br />
(1K), 1048576 (1M), 1073741824 (1G), 1099511627776 (1T), 1125899906842624<br />
(1P) or the number of bytes in an integer, respectively. Two or more<br />
numbers may be separated by an ``x'' to indicate a product.<br />
<br />
: — [[User:Goetzc|Goetzc]] ([[User talk:Goetzc|talk]]) 17:21, 11 August 2019 (UTC)<br />
<br />
::I should clarify, again. As I mentioned before, this specific Talk section is not really about which command is correct for each OS; that's a "technical" matter, and in _theory_ it should be quite "easy" to find out the "correct" one.<br />
::The problem is that, once in awhile, someone decides to "correct" the command in the wiki while betting mom's life that the "corrected" command is truly the "correct" one. And then comes another editor with similar bets/claims but with a slightly different command (e.g. "m" vs. "M"), until a third one steps in (or the first one comes back).<br />
::You know, theory vs. practice; relatively few editors would check a Talk page or open a new discussion before performing an edition, especially when their own "bets" are so "absolutely the winner" ones, "no doubt".<br />
::Then comes some fourth editor, suggesting to eliminate the parts of the command that might generate some conflict while being (seemingly) non-essential, until a fifth editor re-adds the same conflicting option/parameter/argument to the command in question.<br />
::There are also those that suggest that "we should just remove everything", even the parts that are relevant and useful. That's until someone else invests the time to re-add something similar, yet again.<br />
::(Note: I'm not trying to be rude in any way to anyone; I'm trying to clarify a point.) My point is: let's try to add a simple sentence/note that would clarify the matter and lead users (and potential wiki editors) to attempt one command, and if it happens to fail, then try the other, while "leaving the text alone" (instead of this "back_and_forth"). Or (and) link to relevant sources, or (and)... In a certain sense, keep it as simple as possible and as complex as required while being useful in a pragmatic way.<br />
::So, now that I have rephrased the matter (hopefully in a clearer way/scope/perspective), I guess it is time for me to ask... Which is the adequate way/text/format/information that would achieve this balance <u>while reducing/stopping the "back_and_forth" editions</u>?<br />
::Reminder: the command in question is part of a section that (at the time of this writing) is named "In macOS". [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 20:18, 11 August 2019 (UTC)<br />
<br />
:::How about adding something like this:<br />
:::{{Note|The following command uses '''macOS''' ''dd''. The block size is specified differently than for GNU coreutils' ''dd''.}}<br />
::: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:48, 10 February 2020 (UTC)<br />
<br />
::::I added a comment in the page source to future editors not to change it to 'M', and removed the dispute tag ('m' is absolutely correct for the default 'dd' on macOS). Hopefully this is enough. [[User:ColdPie|ColdPie]] ([[User talk:ColdPie|talk]]) 14:06, 4 May 2020 (UTC)<br />
<br />
== Universal replacement for "dd" ==<br />
<br />
I've used "ddrescue" command in the past to create working media for different distributions. It has a "progress bar" built-in as well as error reporting. Should this be the default recommendation now instead of "mere dd"?<br />
<br />
{{unsigned|20:06, 28 December 2016|Beoldhin}}<br />
<br />
:The dd commands on this page include {{ic|1=status=progress}}, which shows the progress. I don't see a reason to add yet another dependency to be installed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:40, 28 December 2016 (UTC)<br />
<br />
== Add section 'Other Methods for UEFI systems' ==<br />
There's a certain amount of EFI devices that need editable(manually formatted) partitions. Such as 32-bit UEFI devices that need custom .efi files added simply in order to boot. How about adding that as a section, since we already have one for BIOS?<br />
<br />
I have included the text that I'd like to add to the article<s>(it's commented out, edit this post to see it)</s>.<br />
<br />
* Create one partition entry in GPT (of type "ef00")<br />
* Create a FAT32 filesystem on such partition replacing $LABEL with the one that corresponds to the archiso label. In case you have an archlinux-2017.03.01.iso, the label is ARCH_201703<br />
* Mount target filesystem. In this example we mount it on /mnt/esp<br />
* Extract ISO image on target filesystem.<br />
* Unmount target filesystem.<br />
<br />
# gdisk /dev/sd'''X'''<br />
# mkfs.fat -F 32 -n $LABEL /dev/sd'''Xn'''<br />
# mount /dev/sd'''Xn''' /mnt/esp<br />
# bsdtar -x --exclude=isolinux/ --exclude=EFI/archiso/ --exclude=arch/boot/syslinux/ -f archlinux-2017.03.01.iso -C /mnt/esp<br />
# umount /mnt/esp<br />
<br />
[[User:Pineman13|Pineman13]] ([[User talk:Pineman13|talk]]) 14:51, 7 January 2017 (UTC)<br />
<br />
== Using manual formatting In GNU/Linux ==<br />
<br />
Is it truth that fs on partition _must_ be FAT32? For uefi it is guaranteed to work, but for some firmware implementations it is also possible to use other fs types as I know. For legacy it could be also ext2/3/4 I guess (even syslinux is called extlinux). So I think it is better to say something like "for better compatibility" instead of "must" here.<br />
<br />
When copying files from mounted iso, maybe add exclude arguments to the command? For example, we could exclude isolinux folder.<br />
<br />
Actually, in instructions here: https://git.archlinux.org/archiso.git/tree/docs/README.transfer they mention another FSs and use excludes in extraction command. [[User:Ashark|Ashark]] ([[User talk:Ashark|talk]]) 17:47, 25 April 2019 (UTC)<br />
<br />
== dd-ed ISO to USB device + new partition for user data transfer - without failing to boot ==<br />
<br />
If for whatever reason, user does not want to use either of [[USB_flash_installation_media#Using_manual_formatting]] (because it requires FAT32 for example) or [[USB_flash_installation_media#Using_a_multiboot_USB_drive]], then here's a way to still be able boot (without failing into rescue shell) in the case when you did dd the image to the usb (via [[USB_flash_installation_media#Using_dd]]) and took the additional step to make a new partition for extra data that you wanted to have available during installation for example.<br />
<br />
Due to the way systemd identifies {{ic|1=by-label}} mounts for isohybrid ISOs (see issue in https://github.com/systemd/systemd/issues/12409 ) of which archlinux*.iso is one, you have to use kernel cmdline {{ic|1=archiso''device''=/dev/disk/by-partuuid/'''ISOUUID'''-01}} where {{ic|1=ISOUUID}} is what you get when you execute {{ic|1=blkid -p archlinux-2019.04.01-x86_64.iso}} seen in its output as {{ic|1=PTUUID="377032cf"}} (don't forget to add that {{ic|1=-01}} which means the first partition (which is the 600M iso one)), for example: {{ic|1=archisodevice=/dev/disk/by-partuuid/377032cf-01}}. For other ways to pass archisodevice to kernel cmdline, see how it's being done inside the section [[USB_flash_installation_media#Using_manual_formatting]]. Note: I've only tested grub boot (so non-UEFI) with this method and I was thus able to mount my new partition this way. Without this {{ic|1=by-partuuid}} trick, booting the iso from the USB device will fail at mounting airootfs, then if workaround it by just giving your new partition a label, it will boot ok but you won't be able to mount this new partition (details in the aforementioned systemd issue on github). [[User:Howaboutsynergy|Howaboutsynergy]] ([[User talk:Howaboutsynergy|talk]]) 22:35, 13 May 2019 (UTC)<br />
<br />
== Rufus ISO Image Mode no longer works ==<br />
<br />
From the looks of it DD Image Mode is now required. I've only tested it with UEFI. [[User:Tonij|Tonij]] ([[User talk:Tonij|talk]]) 15:15, 7 March 2020 (UTC)</div>ColdPiehttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=610828USB flash installation medium2020-05-04T14:05:29Z<p>ColdPie: Remove accuracy tag, add a comment for future editors.</p>
<hr />
<div>[[Category:Installation process]]<br />
[[ar:USB flash installation media]]<br />
[[bg:USB flash installation media]]<br />
[[de:Installation von einem USB-Stick]]<br />
[[es:USB flash installation media]]<br />
[[fr:Créer une clef USB avec l'ISO Arch Linux]]<br />
[[it:USB flash installation media]]<br />
[[ja:USB インストールメディア]]<br />
[[pt:USB flash installation media]]<br />
[[ru:USB flash installation media]]<br />
[[zh-hans:USB flash installation media]]<br />
[[zh-hant:USB flash installation media]]<br />
{{Related articles start}}<br />
{{Related|CD Burning}}<br />
{{Related|Archiso}}<br />
{{Related|Multiboot USB drive}}<br />
{{Related articles end}}<br />
<br />
{{Move|USB flash installation medium|The title should use a singular form.}}<br />
<br />
This page discusses various multi-platform methods on how to create an Arch Linux Installer USB drive (also referred to as ''"flash drive", "USB stick", "USB key"'', etc) for booting in BIOS and UEFI systems. The result will be a LiveUSB (LiveCD-like) system that can be used for installing Arch Linux, system maintenance or for recovery purposes, and that, because of the nature of [[Wikipedia:SquashFS|SquashFS]], will discard all changes once the computer shuts down.<br />
<br />
If you would like to run a full install of Arch Linux from a USB drive (i.e. with persistent settings), see [[Installing Arch Linux on a USB key]]. If you would like to use your bootable Arch Linux USB stick as a rescue USB, see [[Change root]].<br />
<br />
== BIOS and UEFI bootable USB ==<br />
<br />
=== Using automatic tools ===<br />
<br />
==== In GNU/Linux ====<br />
<br />
===== Using dd =====<br />
<br />
{{Note|This method is recommended due to its simplicity. If it does not work, switch to the alternative method [[#Using manual formatting]] below.}}<br />
<br />
{{Warning|This will irrevocably destroy all data on {{ic|/dev/'''sdx'''}}. To restore the USB drive as an empty, usable storage device after using the Arch ISO image, the ISO 9660 filesystem signature needs to be removed by running {{ic|wipefs --all /dev/'''sdx'''}} as root, before [[repartition]]ing and [[reformat]]ting the USB drive.}}<br />
<br />
{{Tip|Find out the name of your USB drive with {{ic|lsblk}}. Make sure that it is '''not''' mounted.}}<br />
<br />
Run the following command, replacing {{ic|/dev/'''sdx'''}} with your drive, e.g. {{ic|/dev/sdb}}. (Do '''not''' append a partition number, so do '''not''' use something like {{ic|/dev/sdb'''1'''}})<br />
<br />
# dd bs=4M if=path/to/archlinux.iso of=/dev/'''sdx''' status=progress oflag=sync<br />
<br />
See {{man|1|dd}} for more information about [[dd]]. See {{man|1|dd|DESCRIPTION}} for more information about {{ic|1=oflag=sync}}.<br />
<br />
{{Tip|If the UEFI version of the USB's Arch ISO hangs or is unable to load, try repeating the [[dd]] medium creation process on the same USB drive one or more times.}}<br />
<br />
===== Using MultiWriter =====<br />
<br />
{{pkg|gnome-multi-writer}} is a simple gtk3 based graphical tool to write an ISO file to one or multiple USB devices at once.<br />
<br />
===== Using Kindd =====<br />
<br />
[https://github.com/LinArcX/Kindd Kindd] is a Qt based graphical frontend for dd. It is available as {{AUR|kindd}}.<br />
<br />
===== Using etcher =====<br />
<br />
[https://etcher.io/ Etcher] is a OS image flasher built with node.js and Electron, capable of flashing an SDCard or USB drive. It protects you from accidentally writing to your hard-drives and ensures every byte of data was written correctly. There are [https://aur.archlinux.org/packages/?SeB=n&K=etcher 5 related packages] in the AUR.<br />
<br />
==== In Windows ====<br />
<br />
===== Using Rufus =====<br />
<br />
[https://rufus.akeo.ie/ Rufus] is a multi-purpose USB ISO writer. It provides a graphical user interface and does not care if the drive is properly formatted or not.<br />
<br />
Simply select the Arch Linux ISO, the USB drive you want to create the bootable Arch Linux onto and click ''START''.<br />
<br />
{{Note|If the USB drive does not boot properly using the default ISO Image mode, '''DD Image mode''' should be used instead.<br />
* For Rufus version ≥ 3.0 select ''GPT'' from the ''Partition scheme'' drop-down menu. After clicking ''START'' you will get the mode selection dialog, select ''DD Image mode''.<br />
* For Rufus version < 3.0 select ''DD Image'' mode from the drop-down menu on the bottom.<br />
}}<br />
<br />
{{Tip|To add [https://github.com/pbatard/rufus/issues/691 an additional partition for persistent storage] use the slider to choose the persistent partition's size. When using the persistent partition feature, make sure to select ''MBR'' in the ''Partition scheme'' drop-down menu and ''BIOS or UEFI'' in ''Target System'', otherwise the drive will not be usable for both BIOS and UEFI booting.}}<br />
<br />
===== Using USBwriter =====<br />
<br />
This method does not require any workaround and is as straightforward as {{ic|dd}} under Linux. Just download the Arch Linux ISO, and with local administrator rights use the [https://sourceforge.net/p/usbwriter/wiki/Documentation/ USBwriter] utility to write to your USB flash memory.<br />
<br />
===== Using win32diskimager =====<br />
<br />
[https://sourceforge.net/projects/win32diskimager/ win32diskimager] is another graphical USB iso writing tool for Windows. Simply select your iso image and the target USB drive letter (you may have to format it first to assign it a drive letter), and click Write. <br />
<br />
===== Using Cygwin =====<br />
<br />
Make sure your [https://www.cygwin.com/ Cygwin] installation contains the {{ic|dd}} package.<br />
<br />
{{Tip|If you do not want to install Cygwin, you can download {{ic|dd}} for Windows from [http://www.chrysocome.net/dd here]. See the next section for more information.}}<br />
<br />
Place your image file in your home directory:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\'''x''': bs=4M<br />
<br />
where image.iso is the path to the iso image file within the {{ic|cygwin}} directory and {{ic|\\.\'''x''':}} is your USB flash drive where {{ic|'''x'''}} is the windows designated letter, e.g. {{ic|\\.\d:}}.<br />
<br />
On Cygwin 6.0, find out the correct partition with:<br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
{{Warning|This will irrevocably delete all files on your USB flash drive, so make sure you do not have any important files on the flash drive before doing this.}}<br />
<br />
dd if=image.iso of=/dev/sdb bs=4M<br />
<br />
===== dd for Windows =====<br />
<br />
A GPL licensed dd version for Windows is available at http://www.chrysocome.net/dd. The advantage of this over Cygwin is a smaller download. Use it as shown in instructions for Cygwin above.<br />
<br />
To begin, download the latest version of dd for Windows. Once downloaded, extract the archive's contents into Downloads or elsewhere.<br />
<br />
Now, launch your {{ic|command prompt}} as an administrator. Next, change directory ({{ic|cd}}) into the Downloads directory.<br />
<br />
If your Arch Linux ISO is elsewhere you may need to state the full path, for convenience you may wish to put the Arch Linux ISO into the same folder as the dd executable. The basic format of the command will look like this.<br />
<br />
# dd if=''archlinux-''version''-x86_64.iso'' od=\\.\''x'': bs=4M<br />
<br />
{{Note|The Windows drive letters are linked to a partition. To allow selecting the entire disk, ''dd for Windows'' provides the {{ic|od}} parameter, which is used in the commands above. Note however that this parameter is specific to ''dd for Windows'' and cannot be found in other implementations of ''dd''.}}<br />
<br />
{{Warning|Because the {{ic|od}} is used, all partitions on the selected disk will be destroyed. Be absolutely sure that you are directing dd to the correct drive before executing.}}<br />
<br />
Simply replace the various null spots (indicated by an "x") with the correct date and correct drive letter. Here is a complete example.<br />
<br />
# dd if=ISOs\archlinux-''version''-x86_64.iso od=\\.\d: bs=4M<br />
<br />
{{Accuracy|The following note may be invalid, the [http://www.chrysocome.net/dd upstream documentation] does not mention anything related to ''PhysicalDrive''.|section=dd for windows}}<br />
<br />
{{Note|Alternatively, replace the drive letter with {{ic|\\.\PhysicalDrive''X''}}, where {{ic|''X''}} is the physical drive number (starts from 0). Example:<br />
{{bc|1=# dd if=ISOs\archlinux-''version''-x86_64.iso of=\\.\PhysicalDrive1 bs=4M}}<br />
You can find out the physical drive number by typing {{ic|wmic diskdrive list brief}} at the command prompt or with {{ic|dd --list}}<br />
Any Explorer window must be closed or dd will report an error.}}<br />
<br />
==== In macOS ====<br />
<br />
First, you need to identify the USB device. Open {{ic|/Applications/Utilities/Terminal}} and list all storage devices with the command:<br />
<br />
$ diskutil list<br />
<br />
Your USB device will appear as something like {{ic|/dev/disk2 (external, physical)}}. Verify that this is the device you want to erase by checking its name and size and then use its identifier for the commands below instead of /dev/diskX.<br />
<br />
A USB device is normally auto-mounted in macOS, and you have to unmount (not eject) it before block-writing to it with {{ic|dd}}. In Terminal, do:<br />
<br />
$ diskutil unmountDisk /dev/diskX<br />
<br />
Now copy the ISO image file to the device. The {{ic|dd}} command is similar to its Linux counterpart, but notice the 'r' before 'disk' for raw mode which makes the transfer much faster:<br />
<br />
# dd if=path/to/arch.iso of=/dev/'''r'''diskX bs=1m <!-- Editor's Note: lower-case 'm' is correct for macOS! Do NOT change this to 'M'! --><br />
<br />
This command will run silently. To view progress, send SIGINFO by pressing {{ic|Ctrl+t}}. Note {{ic|diskX}} here should not include the {{ic|s1}} suffix, or else the USB device will only be bootable in UEFI mode and not legacy. After completion, macOS may complain that "The disk you inserted was not readable by this computer". Select 'Ignore'. The USB device will be bootable.<br />
<br />
==== In Android ====<br />
<br />
===== EtchDroid =====<br />
<br />
[https://etchdroid.depau.eu/ EtchDroid] is a OS image flasher for Android. It works without root permissions on Android 5 to Android 8. According to bug reports it doesn't always work on Android 9 and Android 4.4.<br />
<br />
To create an Arch Linux installer, download the ISO image file on your Android device. Plug the USB drive to your device, using a USB-OTG adapter if needed. Open EtchDroid, select "Flash raw image", select your Arch ISO, then select your USB drive. Grant the USB API permission and confirm.<br />
<br />
Keep your phone on a table while it's writing the image: a lot of USB-OTG adapters are a bit wobbly and you might unplug it by mistake.<br />
<br />
=== Using manual formatting===<br />
<br />
==== In GNU/Linux ====<br />
<br />
This method is more complicated than writing the image directly with {{ic|dd}}, but it does keep the flash drive usable for data storage (that is, the ISO is installed in a specific partition within the already [[Partitioning|partitioned device]] without altering other partitions).<br />
<br />
{{Note|Here, we will denote the targeted partition as {{ic|/dev/sd'''Xn'''}}. In any of the following commands, adjust '''X''' and '''n''' according to your system.}}<br />
<br />
* If not done yet, create a [[partition table]] on {{ic|/dev/sd'''X'''}}.<br />
* If not done yet, create a partition on the device. The partition {{ic|/dev/sd'''Xn'''}} must be formatted to [[FAT32]].<br />
* Mount the ISO image, mount the FAT32 filesystem located in the USB flash device, and copy the contents of the ISO image to it. Then unmount the ISO image, but keep the FAT32 partition mounted (this may be used in subsequent steps). For example:<br />
<br />
# mkdir -p /mnt/{iso,usb}<br />
# mount -o loop archlinux-''version''-x86_64.iso /mnt/iso<br />
# mount /dev/sd'''Xn''' /mnt/usb<br />
# cp -a /mnt/iso/* /mnt/usb<br />
# sync<br />
# umount /mnt/iso<br />
<br />
To boot either a label or an [[UUID]] to select the partition to boot from is required. By default the label {{ic|ARCH_''YYYYMM''}} (with the appropriate release year and month) is used. Thus, the [[Persistent block device naming#by-label|file system’s label]] has to be set accordingly, for example using ''gparted''. Alternatively, you can change this behaviour by altering the lines ending by {{ic|1=archisolabel=ARCH_''YYYYMM''}} in the file {{ic|/mnt/usb/arch/boot/syslinux/archiso_sys.cfg}} (for BIOS boot), and in {{ic|/mnt/usb/loader/entries/archiso-x86_64.conf}} (for UEFI boot). To use an UUID instead, replace those portions of lines with {{ic|1=archiso''device''=/dev/disk/by-uuid/'''YOUR-UUID'''}}. The UUID can be retrieved with {{ic|1=blkid -o value -s UUID /dev/sd'''Xn'''}}.<br />
<br />
{{Warning|Mismatching labels or wrong UUID prevents booting from the created medium.}}<br />
<br />
Syslinux files for BIOS systems are already copied to {{ic|/mnt/usb/arch/boot/syslinux}}. Install the {{Pkg|syslinux}} package and follow [[Syslinux#Manual install]] instructions to make the partition bootable.<br />
<br />
==== In Windows ====<br />
<br />
{{Note|<br />
* For manual formatting, do not use any '''Bootable USB Creator utility''' for creating the UEFI bootable USB. For manual formatting, do not use ''dd for Windows'' to dd the ISO to the USB drive either.<br />
* In the below commands, '''X:''' is assumed to be the USB flash drive in Windows.<br />
* Windows uses backward slash {{ic|\}} as path-separator, so the same is used in the below commands.<br />
* All commands should be run in Windows command prompt '''as administrator'''.<br />
* {{ic|>}} denotes the Windows command prompt.<br />
}}<br />
<br />
* Partition and format the USB drive using [https://rufus.akeo.ie/ Rufus USB partitioner]. Select partition scheme option as '''MBR for BIOS and UEFI''' and File system as '''FAT32'''. Uncheck "Create a bootable disk using ISO image" and "Create extended label and icon files" options.<br />
* Change the '''Volume Label''' of the USB flash drive {{ic|X:}} to match the LABEL mentioned in the {{ic|1=archisolabel=}} part in {{ic|<ISO>\loader\entries\archiso-x86_64.conf}}. This step is required for Official ISO ([[Archiso]]). This step can be also performed using Rufus, during the prior "partition and format" step.<br />
* Extract the ISO (similar to extracting ZIP archive) to the USB flash drive using [https://www.7-zip.org/ 7-Zip]. <br />
* Download official Syslinux 6.xx binaries (zip file) from https://www.kernel.org/pub/linux/utils/boot/syslinux/ and extract it. The version of Syslinux should be the same version used in the ISO image.<br />
<br />
* Run the following command (in Windows cmd prompt, as admin):<br />
<br />
> cd bios\<br />
> for /r %Y in (*.c32) do copy "%Y" "X:\arch\boot\syslinux\" /y<br />
> copy mbr\*.bin X:\arch\boot\syslinux\ /y<br />
<br />
* Install Syslinux to the USB by running (use {{ic|win64\syslinux64.exe}} for x64 Windows):<br />
<br />
> cd bios\<br />
> win32\syslinux.exe -d /arch/boot/syslinux -i -a -m X:<br />
<br />
{{Note|<br />
* The above step installs Syslinux's {{ic|ldlinux.sys}} to the VBR of the USB partition, sets the partition as "active/boot" in the MBR partition table and writes the MBR boot code to the 1st 440-byte boot code region of the USB.<br />
* The {{ic|-d}} switch expects a path with forward slash path-separator like in *unix systems.<br />
}}<br />
<br />
== Other methods for BIOS systems ==<br />
<br />
=== In GNU/Linux ===<br />
<br />
==== Using a multiboot USB drive ====<br />
<br />
This allows booting multiple ISOs from a single USB device, including the archiso. Updating an existing USB drive to a more recent ISO is simpler than for most other methods. See [[Multiboot USB drive]].<br />
<br />
==== Using GNOME Disk Utility ====<br />
<br />
Linux distributions running GNOME can easily make a live CD through {{Pkg|nautilus}} and {{Pkg|gnome-disk-utility}}. Simply right-click on the ''.iso'' file, and select ''Open With Disk Image Writer''. When GNOME Disk Utility opens, specify the flash drive from the ''Destination'' drop-down menu and click ''Start Restoring''.<br />
<br />
==== Making a USB-ZIP drive ====<br />
<br />
For some old BIOS systems, only booting from USB-ZIP drives is supported. This method allows you to still boot from a USB-HDD drive.<br />
<br />
{{Warning|This will destroy all information on your USB flash drive!}}<br />
<br />
* Download {{Pkg|syslinux}} and {{Pkg|mtools}} from the official repositories.<br />
* Find your usb drive with {{ic|lsblk}}.<br />
* Type {{ic|mkdiskimage -4 /dev/sd'''x''' 0 64 32}} (replace x with the letter of your drive). This will take a while.<br />
<br />
From here continue with the manual formatting method. The partition will be {{ic|/dev/sd'''x'''4}} due to the way ZIP drives work.<br />
<br />
{{Note|Do not format the drive as FAT32; keep it as FAT16.}}<br />
<br />
==== Using UNetbootin ====<br />
<br />
UNetbootin can be used on any Linux distribution or Windows to copy your iso to a USB device. However, Unetbootin overwrites {{ic|syslinux.cfg}}, so it creates a USB device that does not boot properly. For this reason, '''Unetbootin is not recommended''' -- please use {{ic|dd}} or one of the other methods discussed in this topic.<br />
<br />
{{Warning|UNetbootin writes over the default {{ic|syslinux.cfg}}; this must be restored before the USB device will boot properly.}}<br />
<br />
Edit {{ic|syslinux.cfg}}:<br />
<br />
{{hc|sysconfig.cfg|2=<br />
default menu.c32<br />
prompt 0<br />
menu title Archlinux Installer<br />
timeout 100<br />
<br />
label unetbootindefault<br />
menu label Archlinux_x86_64<br />
kernel /arch/boot/x86_64/vmlinuz<br />
append initrd=/arch/boot/x86_64/archiso.img archisodevice=/dev/sd'''x1''' ../../<br />
}}<br />
<br />
In {{ic|/dev/sd'''x1'''}} you must replace '''x''' with the first free letter after the last letter in use on the system where you are installing Arch Linux (e.g. if you have two hard drives, use {{ic|c}}.). You can make this change during the first phase of boot by pressing {{ic|Tab}} when the menu is shown.<br />
<br />
=== In Windows ===<br />
<br />
==== The Flashnul way ====<br />
<br />
[https://translate.google.com/translate?hl=&sl=ru&tl=en&u=http%3A%2F%2Fshounen.ru%2Fsoft%2Fflashnul%2Freadme.rus.html&sandbox=1 flashnul] is an utility to verify the functionality and maintenance of Flash-Memory (USB-Flash, IDE-Flash, SecureDigital, MMC, MemoryStick, SmartMedia, XD, CompactFlash etc).<br />
<br />
From a command prompt, invoke flashnul with {{ic|-p}}, and determine which device index is your USB drive, e.g.:<br />
<br />
{{hc|C:\>flashnul -p|<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
}}<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, {{ic|-L}}, and the path to your image, e.g:<br />
<br />
C:\>flashnul '''E:''' -L ''path\to\arch.iso''<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
{{Note|Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64.}}<br />
<br />
==== Loading the installation medium from RAM ====<br />
<br />
{{Merge|Multiboot USB drive#Using Syslinux and memdisk|This is the same method, only Syslinux is installed from Windows. Considering that [[multiboot USB drive]] can be used to boot an installation medium and it is already linked from the Related articles box at the top, maybe this section should be merged there?}}<br />
<br />
This method uses [[Syslinux]] and a [[Ramdisk]] ([https://wiki.syslinux.org/wiki/index.php/MEMDISK MEMDISK]) to load the entire Arch Linux ISO image into RAM. Since this will be running entirely from system memory, you will need to make sure the system you will be installing this on has an adequate amount. A minimum amount of RAM between 500 MB and 1 GB should suffice for a MEMDISK based, Arch Linux install.<br />
<br />
For more information on Arch Linux system requirements as well as those for MEMDISK see the [[Installation guide]] and [http://www.etherboot.org/wiki/bootingmemdisk#preliminaries here]. For reference, here is the [https://bbs.archlinux.org/viewtopic.php?id=135266 preceding forum thread].<br />
<br />
{{Tip|Once the installer has completed loading you can simply remove the USB stick and even use it on a different machine to start the process all over again. Utilizing MEMDISK also allows booting and installing Arch Linux to and from the same USB flash drive.}}<br />
<br />
===== Preparing the USB flash drive =====<br />
<br />
Begin by formatting the USB flash drive as '''FAT32'''. Then create the following folders on the newly formatted drive.<br />
<br />
* {{ic|Boot}}<br />
** {{ic|Boot/ISOs}}<br />
** {{ic|Boot/Settings}}<br />
<br />
===== Copy the needed files to the USB flash drive =====<br />
<br />
Next copy the ISO that you would like to boot to the {{ic|Boot/ISOs}} folder. After that, extract from the following files from the latest release of {{pkg|syslinux}} from [https://www.kernel.org/pub/linux/utils/boot/syslinux/ here] and copy them into the following folders.<br />
* {{ic|./win32/syslinux.exe}} to the Desktop or Downloads folder on your system.<br />
* {{ic|./memdisk/memdisk}} to the {{ic|Settings}} folder on your USB flash drive.<br />
<br />
===== Create the configuration file =====<br />
<br />
After copying the needed files, navigate to the USB flash drive, /boot/Settings and create a {{ic|syslinux.cfg}} file.<br />
<br />
{{Warning|On the {{ic|INITRD}} line, be sure to use the name of the ISO file that you copied to your {{ic|ISOs}} folder.}}<br />
<br />
{{hc|/Boot/Settings/syslinux.cfg|2=<br />
DEFAULT arch_iso<br />
<br />
LABEL arch_iso<br />
MENU LABEL Arch Setup<br />
LINUX memdisk<br />
INITRD /Boot/ISOs/archlinux-''version''-x86_64.iso<br />
APPEND iso<br />
}}<br />
<br />
For more information on Syslinux see the [[Syslinux|Arch Wiki article]].<br />
<br />
===== Final steps =====<br />
<br />
Finally, create a {{ic|*.bat}} file where {{ic|syslinux.exe}} is located and run it ("Run as administrator" if you are on Vista or Windows 7):<br />
<br />
{{hc|C:\Documents and Settings\username\Desktop\install.bat|<br />
@echo off<br />
syslinux.exe -m -a -d /Boot/Settings X:<br />
}}<br />
<br />
== Troubleshooting ==<br />
<br />
* If you get the "device did not show up after 30 seconds" error due to the {{ic|/dev/disk/by-label/ARCH_''YYYYMM''}} not mounting, try renaming your USB medium to {{ic|ARCH_''YYYYMM''}} (e.g. {{ic|ARCH_201501}}).<br />
* If you get errors, try using another USB device. There are case scenarios in which it solved all issues.<br />
<br />
== See also ==<br />
<br />
* [https://wiki.gentoo.org/wiki/LiveUSB/HOWTO Gentoo wiki - LiveUSB/HOWTO]<br />
* [https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB Fedora wiki - How to create and use Live USB]<br />
* [https://en.opensuse.org/SDB:Live_USB_stick openSUSE wiki - SDB:Live USB stick]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=584002Unified Extensible Firmware Interface2019-09-27T15:20:03Z<p>ColdPie: /* System boots to EFI shell after hardware change or starting other operating system */ Make it less GRUB-specific</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:Unified Extensible Firmware Interface]]<br />
[[it:Unified Extensible Firmware Interface]]<br />
[[ja:Unified Extensible Firmware Interface]]<br />
[[ru:Unified Extensible Firmware Interface]]<br />
[[zh-hans:Unified Extensible Firmware Interface]]<br />
{{Related articles start}}<br />
{{Related|EFI system partition}}<br />
{{Related|Arch boot process}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Secure Boot}}<br />
{{Related articles end}}<br />
{{Warning|While the choice to install in UEFI mode is forward looking, early vendor UEFI implementations ''may'' carry more bugs than their BIOS counterparts. It is advised to do a search relating to your particular motherboard model before proceeding.}}<br />
<br />
The [https://www.uefi.org/ Unified Extensible Firmware Interface] (UEFI or EFI for short) is a new model for the interface between operating systems and firmware. It provides a standard environment for booting an operating system and running pre-boot applications.<br />
<br />
It is distinct from the commonly used "[[Partitioning#Master Boot Record (bootstrap code)|MBR boot code]]" method followed for [[Wikipedia:BIOS|BIOS]] systems. See [[Arch boot process]] for their differences and the boot process using UEFI. To set up UEFI boot loaders, see [[Arch boot process#Boot loader]].<br />
<br />
== UEFI versions ==<br />
<br />
* UEFI started as Intel's EFI in versions 1.x.<br />
* Later, a group of companies called the UEFI Forum took over its development, which renamed it as Unified EFI starting with version 2.0.<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware.<br />
* Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one (U)EFI specification and therefore is not a standard UEFI firmware. Unless stated explicitly, these instructions are general and some of them may not work or may be different in [[MacBook|Apple Macs]].<br />
<br />
The latest UEFI specification can be found at https://uefi.org/specifications.<br />
<br />
== UEFI firmware bitness ==<br />
<br />
Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a EFI application corresponding to the UEFI firmware bitness/architecture.<br />
<br />
The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 UEFI firmware. The only known devices that use IA32 (32-bit) UEFI are older (pre 2008) Apple Macs, Intel Atom System-on-Chip systems (as on 2 November 2013)[https://software.intel.com/en-us/blogs/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems] and some older Intel server boards that are known to operate on Intel EFI 1.10 firmware.<br />
<br />
An x86_64 UEFI firmware does not include support for launching 32-bit EFI applications (unlike x86_64 Linux and Windows versions which include such support). Therefore the EFI application must be compiled for that specific firmware processor bitness/architecture.<br />
<br />
{{Note|The official ISO does not support booting on 32-bit (IA32) UEFI systems, see [[#Booting 64-bit kernel on 32-bit UEFI]] for available workarounds. The installed system will require using a boot loader that supports IA32 UEFI, for example, [[GRUB]] with the {{ic|i386-efi}} target.}}<br />
<br />
=== Checking the firmware bitness ===<br />
<br />
The firmware bitness can be checked from a booted operating system.<br />
<br />
==== From Linux ====<br />
<br />
On distributions running Linux kernel 4.0 or newer, the UEFI firmware bitness can be found via the sysfs interface. Run:<br />
<br />
$ cat /sys/firmware/efi/fw_platform_size<br />
<br />
It will return {{ic|64}} for a 64-bit (x86_64) UEFI or {{ic|32}} for a 32-bit (IA32) UEFI. If the file does not exist, then you have not booted in UEFI mode.<br />
<br />
==== From macOS ====<br />
<br />
Pre-2008 [[Mac]]s mostly have IA32 EFI firmware while >=2008 Macs have mostly x86_64 EFI. All Macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware.<br />
<br />
To find out the arch of the EFI firmware in a Mac, type the following into the Mac OS X terminal:<br />
<br />
$ ioreg -l -p IODeviceTree | grep firmware-abi<br />
<br />
If the command returns {{ic|EFI32}} then it is IA32 (32-bit) EFI firmware. If it returns {{ic|EFI64}} then it is x86_64 EFI firmware. Most of the Macs do not have UEFI 2.x firmware as Apple's EFI implementation is not fully compliant with UEFI 2.x specification.<br />
<br />
==== From Microsoft Windows ====<br />
<br />
64-bit versions of Windows do not support booting on a 32-bit UEFI. So, if you have a 32-bit version of Windows booted in UEFI mode, you have a 32-bit UEFI.<br />
<br />
To check the bitness run {{ic|msinfo32.exe}}. In the ''System Summary'' section look at the values of "System Type" and "BIOS mode".<br />
<br />
For a 64-bit Windows on a 64-bit UEFI it will be {{ic|System Type: x64-based PC}} and {{ic|BIOS mode: UEFI}}, for a 32-bit Windows on a 32-bit UEFI - {{ic|System Type: x86-based PC}} and {{ic|BIOS mode: UEFI}}. If the "BIOS mode" is not {{ic|UEFI}}, then Windows is not installed in UEFI mode.<br />
<br />
== Linux kernel config options for UEFI ==<br />
<br />
The required Linux Kernel configuration options[https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txt] for UEFI systems are:<br />
<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_EFI=y<br />
CONFIG_EFI_STUB=y<br />
CONFIG_X86_SYSFB=y<br />
CONFIG_FB_SIMPLE=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
UEFI Runtime Variables Support ('''efivarfs''' filesystem - {{ic|/sys/firmware/efi/efivars}}). This option is important as this is required to manipulate UEFI runtime variables using tools like {{ic|/usr/bin/efibootmgr}}. The below config option has been added in kernel 3.10 and above.<br />
<br />
CONFIG_EFIVAR_FS=y<br />
<br />
UEFI Runtime Variables Support (old '''efivars sysfs''' interface - {{ic|/sys/firmware/efi/vars}}). This option should be disabled to prevent any potential issues with both efivarfs and sysfs-efivars enabled.<br />
<br />
CONFIG_EFI_VARS=n<br />
<br />
[[GUID Partition Table]] (GPT) config option - mandatory for UEFI support<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
EFI mixed-mode support - to boot a x64_64 kernel on a IA32 UEFI.<br />
<br />
CONFIG_EFI_MIXED=y<br />
<br />
{{Note|All of the above options are enabled in Arch Linux [[kernels]] in the official repositories.}}<br />
<br />
== UEFI variables ==<br />
<br />
UEFI defines variables through which an operating system can interact with the firmware. UEFI boot variables are used by the boot loader and used by the OS only for early system start-up. UEFI runtime variables allow an OS to manage certain settings of the firmware like the UEFI boot manager or managing the keys for UEFI Secure Boot protocol etc. You can get the list using:<br />
<br />
$ efivar --list<br />
<br />
=== UEFI variables support in Linux kernel ===<br />
<br />
Linux kernel exposes UEFI variables data to userspace via '''efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface ({{ic|CONFIG_EFIVAR_FS}}) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - it has no maximum per-variable size limitation and supports UEFI Secure Boot variables. Introduced in kernel 3.8.<br />
<br />
=== Requirements for UEFI variable support ===<br />
<br />
# Kernel should be booted in UEFI mode via [[EFISTUB]] (optionally using a [[boot manager]]) or by a UEFI [[boot loader]] (using either the EFI handover protocol or the UEFI LoadImage function), not via BIOS or CSM, or Apple's Boot Camp which is also a CSM.<br />
# EFI Runtime Services support should be present in the kernel ({{ic|1=CONFIG_EFI=y}}, check if present with {{ic|zgrep CONFIG_EFI /proc/config.gz}}).<br />
# EFI Runtime Services in the kernel SHOULD NOT be disabled via kernel cmdline, i.e. {{ic|noefi}} kernel parameter SHOULD NOT be used.<br />
# {{ic|efivarfs}} filesystem should be mounted at {{ic|/sys/firmware/efi/efivars}}, otherwise follow [[#Mount efivarfs]] section below.<br />
# {{ic|efivar}} should list (option {{ic|-l}}/{{ic|--list}}) the UEFI variables without any error.<br />
<br />
If UEFI Variables support does not work even after the above conditions are satisfied, try the below workarounds:<br />
<br />
# If any userspace tool is unable to modify UEFI variable data, check for existence of {{ic|/sys/firmware/efi/efivars/dump-*}} files. If they exist, delete them, reboot and retry again.<br />
# If the above step does not fix the issue, try booting with {{ic|efi_no_storage_paranoia}} kernel parameter to disable kernel UEFI variable storage space check that may prevent writing/modification of UEFI variables.<br />
<br />
{{Warning|{{ic|efi_no_storage_paranoia}} should only be used when needed and should not be left as a normal boot option. The effect of this kernel command line parameter turns off a safeguard that was put in place to help avoid the bricking of machines when the NVRAM gets too full. See {{Bug|34641}} for more information.}}<br />
<br />
==== Mount efivarfs ====<br />
<br />
If {{ic|efivarfs}} is not automatically mounted at {{ic|/sys/firmware/efi/efivars}} by [[systemd]] during boot, then you need to manually mount it to expose UEFI variables to [[#Userspace tools|userspace tools]] like ''efibootmgr'':<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both '''outside''' ('''before''') and '''inside''' the [[chroot]], if any.}}<br />
<br />
See [https://www.kernel.org/doc/Documentation/filesystems/efivarfs.txt efivarfs.txt] for kernel documentation.<br />
<br />
=== Userspace tools ===<br />
<br />
There are few tools that can access/modify the UEFI variables, namely<br />
<br />
* {{App|efivar|Library and Tool to manipulate UEFI variables (used by efibootmgr)|https://github.com/rhboot/efivar|{{Pkg|efivar}}, {{AUR|efivar-git}}}}<br />
* {{App|efibootmgr|Tool to manipulate UEFI Firmware Boot Manager Settings|https://github.com/rhboot/efibootmgr|{{Pkg|efibootmgr}}}}<br />
* {{App|uefivars|Dumps list of UEFI variables with some additional PCI related info (uses efibootmgr code internally)|https://github.com/fpmurphy/Various/tree/master/uefivars-2.0|{{AUR|uefivars-git}}}}<br />
* {{App|efitools|Tools for manipulating UEFI secure boot platforms|https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git|{{Pkg|efitools}}}}<br />
* {{App|Ubuntu's Firmware Test Suite|Test suite that performs sanity checks on Intel/AMD PC firmware|https://wiki.ubuntu.com/FirmwareTestSuite/|{{AUR|fwts-git}}}}<br />
<br />
==== efibootmgr ====<br />
<br />
You will have to [[install]] the {{Pkg|efibootmgr}} package.<br />
<br />
{{Note|<br />
* If ''efibootmgr'' does not work on your system, you can reboot into [[#UEFI Shell]] and use {{ic|bcfg}} to create a boot entry for the bootloader.<br />
* If you are unable to use {{ic|efibootmgr}}, some UEFI firmwares allow users to directly manage UEFI boot entries from within its boot-time interface. For example, some firmwares have an "Add New Boot Option" choice which enables you to select a local EFI system partition and manually enter the EFI application location e.g. {{ic|\EFI\refind\refind_x64.efi}}.<br />
* The below commands use [[rEFInd]] boot manager as example.<br />
}}<br />
<br />
To add a new boot option using ''efibootmgr'' you need to know three things:<br />
<br />
# The disk containing the [[EFI system partition]] (ESP). E.g.: {{ic|/dev/sda}}, {{ic|/dev/nvme0n1}}.<br />
# The partition number of the ESP on that disk. The {{ic|''Y''}} in {{ic|/dev/sda''Y''}} or {{ic|/dev/nvme0n1p''Y''}}.<br />
# The path to the EFI application (relative to the root of the ESP)<br />
<br />
For example, if you want to add a boot option for {{ic|/efi/EFI/refind/refind_x64.efi}} where {{ic|/efi}} is the mount point of the ESP, run<br />
<br />
{{hc|$ findmnt /efi|2=<br />
TARGET SOURCE FSTYPE OPTIONS<br />
/efi /dev/sda1 vfat rw,flush,tz=UTC<br />
}}<br />
<br />
In this example, this indicates that the ESP is on disk {{ic|/dev/sda}} and has partition number 1. The path to the EFI application relative to the root of the ESP is {{ic|/EFI/refind/refind_x64.efi}}. So you would create the boot entry as follows:<br />
<br />
# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose<br />
<br />
{{Accuracy|{{ic|/dev/nvme0n1p1}} is a partition not a disk, the partition number should be specified using the {{ic|--part}} option.}}<br />
<br />
# efibootmgr --create --disk /dev/nvme0n1p1 --loader /EFI/refind/refind_x64.efi --label "rEFINd Boot Manager" --verbose<br />
<br />
See {{man|8|efibootmgr}} or [https://raw.githubusercontent.com/rhinstaller/efibootmgr/master/README efibootmgr README] for more info.<br />
<br />
{{Note|UEFI uses backward slash {{ic|\}} as path separator but ''efibootmgr'' automatically converts UNIX-style {{ic|/}} path separators.}}<br />
<br />
== UEFI Shell ==<br />
<br />
The UEFI Shell is a shell/terminal for the firmware which allows launching EFI applications which include UEFI bootloaders. Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), modifying boot manager variables (bcfg), running partitioning programs (diskpart), loading UEFI drivers, editing text files (edit), hexedit etc.<br />
<br />
=== Obtaining UEFI Shell ===<br />
<br />
You can download a BSD licensed UEFI Shell from Intel's TianoCore UDK/EDK2 project:<br />
<br />
* [[AUR]] package {{AUR|uefi-shell-git}} (recommended) - provides x86_64 Shell for x86_64 (64-bit) UEFI and IA32 Shell for IA32 (32-bit) UEFI - compiled directly from latest TianoCore EDK2 source.<br />
* There are copies of Shell v1 and Shell v2 in the EFI directory on the Arch install media image.<br />
* [https://github.com/tianocore/edk2/releases/latest/download/ShellBinPkg.zip Precompiled UEFI Shell v2 binaries] (the binary package was moved from its original location in the source tree to the GitHub release assets, as laid out [https://lists.01.org/pipermail/edk2-devel/2019-April/thread.html#38524 here]).<br />
* [https://github.com/tianocore/edk2/tree/UDK2018/EdkShellBinPkg Precompiled UEFI Shell v1 binaries] (not updated anymore upstream as of Jan 10, 2014).<br />
* [https://drive.google.com/uc?export=download&id=1OBXYj6MEs7VAZbYnjD9FxOYcZYIQoq36 Precompiled UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware] - from Clover EFI bootloader.<br />
<br />
Shell v2 works best in UEFI 2.3+ systems and is recommended over Shell v1 in those systems. Shell v1 should work in all UEFI systems irrespective of the spec. version the firmware follows. More info at [https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg ShellPkg] and [https://edk2-devel.narkive.com/zCN4CEnb/inclusion-of-uefi-shell-in-linux-distro-iso this mail].<br />
<br />
=== Launching UEFI Shell ===<br />
<br />
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called {{ic|"Launch EFI Shell from filesystem device"}} . For those motherboards, download the x86_64 UEFI Shell and copy it to your EFI system partition as {{ic|<EFI_SYSTEM_PARTITION>/shellx64.efi}}.<br />
<br />
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either {{ic|F6}}, {{ic|F11}} or {{ic|F12}} key.<br />
<br />
{{Note|If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a [[FAT32]] USB pen drive with {{ic|Shell.efi}} copied as {{ic|(USB)/EFI/BOOT/BOOTx64.EFI}}. This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.}}<br />
<br />
=== Important UEFI Shell commands ===<br />
<br />
UEFI Shell commands usually support {{ic|-b}} option which makes output pause after each page. Run {{ic|help -b}} to list available internal commands. Available commands are either built into the shell or discrete EFI applications.<br />
<br />
For more info see [https://software.intel.com/en-us/articles/efi-shells-and-scripting/ Intel Scripting Guide 2008] and [https://software.intel.com/en-us/articles/uefi-shell Intel "Course" 2011].<br />
<br />
==== bcfg ====<br />
<br />
{{ic|bcfg}} modifies the UEFI NVRAM entries which allows the user to change the boot entries or driver options. This command is described in detail in page 96 (Section 5.3) of the [https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf UEFI Shell Specification 2.2] document.<br />
<br />
{{Note|<br />
* Try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries on your system.<br />
* UEFI Shell v1 official binary does not support {{ic|bcfg}} command. See [[#Obtaining UEFI Shell]] for a modified UEFI Shell v2 binary which may work in UEFI pre-2.3 firmwares.<br />
}}<br />
<br />
To dump a list of current boot entries:<br />
<br />
Shell> bcfg boot dump -v<br />
<br />
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu:<br />
<br />
Shell> bcfg boot add 3 FS0:\EFI\refind\refind_x64.efi "rEFInd"<br />
<br />
where {{ic|FS0:}} is the mapping corresponding to the EFI system partition and {{ic|FS0:\EFI\refind\refind_x64.efi}} is the file to be launched.<br />
<br />
To add an entry to boot directly into your system without a bootloader, configure a boot option using your kernel as an [[EFISTUB#UEFI_Shell|EFISTUB]]:<br />
<br />
Shell> bcfg boot add '''N''' fs'''V''':\vmlinuz-linux "Arch Linux"<br />
Shell> bcfg boot -opt '''N''' "root='''/dev/sdX#''' initrd=\initramfs-linux.img"<br />
<br />
where {{ic|N}} is the priority, {{ic|V}} is the volume number of your EFI system partition, and {{ic|/dev/sdX#}} is your root partition.<br />
<br />
To remove the 4th boot option:<br />
<br />
Shell> bcfg boot rm 3<br />
<br />
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu):<br />
<br />
Shell> bcfg boot mv 3 0<br />
<br />
For bcfg help text:<br />
<br />
Shell> help bcfg -v -b<br />
<br />
or:<br />
<br />
Shell> bcfg -? -v -b<br />
<br />
==== map ====<br />
<br />
{{ic|map}} displays a list of device mappings i.e. the names of available file systems ({{ic|FS0}}) and storage devices ({{ic|blk0}}).<br />
<br />
Before running file system commands such as {{ic|cd}} or {{ic|ls}}, you need to change the shell to the appropriate file system by typing its name:<br />
<br />
Shell> FS0:<br />
FS0:\> cd EFI/<br />
<br />
==== edit ====<br />
<br />
{{ic|edit}} provides a basic text editor with an interface similar to nano, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
For example, to edit rEFInd's {{ic|refind.conf}} in the EFI system partition ({{ic|FS0:}} in the firmware),<br />
<br />
Shell> edit FS0:\EFI\refind\refind.conf<br />
<br />
Type {{ic|Ctrl-E}} for help.<br />
<br />
== UEFI drivers ==<br />
<br />
{{Expansion|Explain what are and how to use UEFI drivers.}}<br />
<br />
== UEFI bootable media ==<br />
<br />
=== Create UEFI bootable USB from ISO ===<br />
<br />
Follow [[USB flash installation media#BIOS and UEFI bootable USB]].<br />
<br />
=== Remove UEFI boot support from optical media ===<br />
<br />
{{Note|<br />
* This section mentions removing UEFI boot support from a '''CD/DVD only''' (Optical Media booting via EL Torito), not from a USB flash drive.<br />
* In order to hide the UEFI equipment on USB stick, use a partition editor after having copied the ISO to the flash drive. Remove the partition of type {{ic|EF}}. '''Do not''' accept offers to convert to GPT.<br />
}}<br />
<br />
Most of the 32-bit EFI Macs and some 64-bit EFI Macs refuse to boot from a UEFI(X64)+BIOS bootable CD/DVD. If one wishes to proceed with the installation using optical media, it might be necessary to remove UEFI support first.<br />
<br />
* Mount the official installation media and obtain the {{ic|archisolabel}} as shown in the previous section.<br />
<br />
# mount -o loop ''input.iso'' /mnt/iso<br />
<br />
* Then rebuild the ISO, excluding the UEFI optical media booting support, using {{ic|xorriso}} from {{pkg|libisoburn}}. Be sure to set the correct archisolabel, e.g. "ARCH_201411" or similar:<br />
<br />
{{bc|1=<br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "''archisolabel''" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared by $USER" \<br />
-eltorito-boot isolinux/isolinux.bin \<br />
-eltorito-catalog isolinux/boot.cat \<br />
-no-emul-boot -boot-load-size 4 -boot-info-table \<br />
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \<br />
-output ''output.iso'' /mnt/iso/<br />
}}<br />
<br />
* Burn {{ic|''output.iso''}} to optical media and proceed with installation normally.<br />
<br />
=== Booting 64-bit kernel on 32-bit UEFI ===<br />
<br />
Official ISO ([[Archiso]]) does not support booting on 32-bit (IA32) UEFI systems ({{Bug|53182}}) since it uses EFISTUB (via [[systemd-boot]] boot manager for menu) for booting the kernel in UEFI mode. To boot a 64-bit kernel with 32-bit UEFI you have to use a boot loader that does not rely on EFI boot stub for launching kernels.<br />
<br />
{{Tip|[[Archboot]] iso supports booting on 32-bit (IA32) UEFI systems.}}<br />
<br />
==== Using GRUB ====<br />
<br />
This section describes how to setup [[GRUB]] as the USB's UEFI bootloader.<br />
<br />
* [[USB flash installation media#Using_manual_formatting|Create an editable USB Flash Installation]]. Since we are going to use GRUB, you only need to follow the steps up until the {{ic|syslinux}} part<br />
<br />
* [[GRUB/Tips and tricks#GRUB standalone|Create a GRUB standalone image]] for 32-bit UEFI systems:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg<br />
# grub-mkstandalone -d /usr/lib/grub/i386-efi -O i386-efi --modules="part_gpt part_msdos" --locales="en@quot" --themes="" -o "''/mnt/usb/''EFI/boot/bootia32.efi" "boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
* Create {{ic|''/mnt/usb''/EFI/boot/grub.cfg}} with the following contents (replace {{ic|ARCH_YYYYMM}} with the required archiso label e.g. {{ic|ARCH_201507}}):<br />
<br />
{{Tip|<br />
* The archiso label can be aquired from the ''.iso'' file with {{ic|isoinfo}} from {{Pkg|cdrtools}} or {{ic|iso-info}} from {{Pkg|libcdio}}.<br />
* The given configuration entries can also be entered inside a [[GRUB#Using_the_command_shell|GRUB command-shell]].<br />
}}<br />
<br />
For the official ISO:<br />
<br />
{{hc|''/mnt/usb''/EFI/boot/grub.cfg|2=<br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux archiso x86_64 UEFI USB" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --label ''ARCH_YYYYMM''<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=''ARCH_YYYYMM'' add_efi_memmap<br />
initrd /arch/boot/intel_ucode.img /arch/boot/x86_64/archiso.img<br />
}<br />
}}<br />
<br />
Durring installation, in the [[Installation guide#Boot loader|boot loader installation step]], [[GRUB#Installation_2|install GRUB]] using the option {{ic|1=--target=i386-efi}}.<br />
<br />
== Testing UEFI in systems without native support ==<br />
<br />
=== OVMF for virtual machines ===<br />
<br />
[https://tianocore.github.io/ovmf/ OVMF] is a TianoCore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware and a separate non-volatile variable store for QEMU.<br />
<br />
You can install {{pkg|ovmf}} from the extra repository.<br />
<br />
It is [https://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt advised] to make a local copy of the non-volatile variable store for your virtual machine:<br />
<br />
$ cp /usr/share/ovmf/x64/OVMF_VARS.fd my_uefi_vars.bin<br />
<br />
To use the OVMF firmware and this variable store, add following to your QEMU command:<br />
<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd \<br />
-drive if=pflash,format=raw,file=my_uefi_vars.bin<br />
<br />
For example:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd -drive if=pflash,format=raw,file=my_uefi_vars.bin …<br />
<br />
=== DUET for BIOS only systems ===<br />
<br />
DUET was a TianoCore project that enabled chainloading a full UEFI environment from a BIOS system, in a way similar to BIOS OS booting. This method is being discussed extensively in https://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/. Pre-build DUET images can be downloaded from one of the repos at https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer. Specific instructions for setting up DUET is available at https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blob/master/Migle_BootDuet_INSTALL.txt . However, as of November 2018, the DUET code has been removed from TianoCore git repository.<br />
<br />
You can also try https://sourceforge.net/projects/cloverefiboot/ which provides modified DUET images that may contain some system specific fixes and is more frequently updated compared to the gitlab repos.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Windows 7 will not boot in UEFI mode ===<br />
<br />
{{Note|Windows 7 can boot in pure UEFI class 3 without CSM support, though installation requires CSM ([https://support.microsoft.com/en-us/kb/2828074 specifically INT 10 H]).}}<br />
<br />
If you have installed Windows to a different hard disk with GPT partitioning and still have a MBR partitioned hard disk in your computer, then it is possible that the firmware (UEFI) is starting its CSM support (for booting MBR partitions) and therefore Windows will not boot. To solve this merge your MBR hard disk to GPT partitioning or disable the SATA port where the MBR hard disk is plugged in or unplug the SATA connector from this hard disk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
* Gigabyte Z77X-UD3H rev. 1.1 (UEFI version F19e)<br />
** The firmware option for booting "UEFI Only" does not prevent the firmware from starting CSM.<br />
<br />
=== Windows changes boot order ===<br />
<br />
If you [[dual boot with Windows]] and your motherboard just boots Windows immediately instead of your chosen EFI application, there are several possible causes and workarounds.<br />
<br />
* Ensure [[Dual boot with Windows#Fast_Start-Up|Fast Startup]] is disabled in your Windows power options<br />
* Ensure [[Secure Boot]] is disabled in your BIOS (if you are not using a signed boot loader)<br />
* Ensure your UEFI boot order does not have Windows Boot Manager set first e.g. using [[#efibootmgr]] and what you see in the configuration tool of the UEFI. Some motherboards override by default any settings set with efibootmgr by Windows if it detects it. This is confirmed in a Packard Bell laptop.<br />
* If your motherboard is booting the default boot path ({{ic|\EFI\BOOT\BOOTX64.EFI}}), this file may have been overwritten with the Windows boot loader. Try setting the correct boot path e.g. using [[#efibootmgr]].<br />
* If the previous steps do not work, you can tell the Windows boot loader to run a different EFI application. From a Windows Administrator command prompt: {{bc|# bcdedit /set "{bootmgr}" path "\EFI\''path''\''to''\''app.efi''"}}<br />
* Alternatively, you can set a startup script in Windows that ensures that the boot order is set correctly every time you boot Windows.<br />
*# Open a command prompt with admin privlages. Run {{ic|bcdedit /enum firmware}} and find your desired boot entry.<br />
*# Copy the Identifier, including the brackets, e.g. {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}<br />
*# Create a batch file with the command {{ic|bcdedit /set "{fwbootmgr}" DEFAULT "{''copied boot identifier''}"}}<br />
*# Open ''gpedit.msc'' and under ''Local Computer Policy > Computer Configuration > Windows Settings > Scripts(Startup/Shutdown)'', choose ''Startup''<br />
*# Under the ''Scripts'' tab, choose the ''Add'' button, and select your batch file<br />
<br />
=== USB media gets struck with black screen ===<br />
<br />
This issue can occur due to [[KMS]] issue. Try [[Kernel mode setting#Disabling_modesetting|Disabling KMS]] while booting the USB.<br />
<br />
=== UEFI boot loader does not show up in firmware menu ===<br />
<br />
On certain UEFI motherboards like some boards with an Intel Z77 chipset, adding entries with {{ic|efibootmgr}} or {{ic|bcfg}} from the UEFI Shell will not work because they do not show up on the boot menu list after being added to NVRAM.<br />
<br />
This issue is caused because the motherboards can only load Microsoft Windows. To solve this you have to place the ''.efi'' file in the location that Windows uses.<br />
<br />
Copy the {{ic|bootx64.efi}} file from the Arch Linux installation medium ({{ic|FSO:}}) to the Microsoft directory your [[ESP]] partition on your hard drive ({{ic|FS1:}}). Do this by booting into EFI shell and typing:<br />
<br />
Shell> mkdir FS1:\EFI\Microsoft<br />
Shell> mkdir FS1:\EFI\Microsoft\Boot<br />
Shell> cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi<br />
<br />
After reboot, any entries added to NVRAM should show up in the boot menu.<br />
<br />
=== System boots to EFI shell after hardware change or starting other operating system ===<br />
<br />
EFI stores state on the motherboard, called EFIVARS. Your bootloader (e.g. GRUB) may need to set up these variables in a certain way in order to boot. If your hardware configuration changes, or you boot into another operating system which overwrites these variables (Windows), you may be dumped into the EFI shell upon attempting to boot Arch Linux since the EFIVARS are incorrect and EFI can no longer find your bootloader.<br />
<br />
At this point, you can use the EFI shell to find and boot your bootloader manually. Usually something like:<br />
<br />
Shell> ls fs0:<br />
EFI\<br />
grub\<br />
<br />
Shell> ls fs0:EFI\<br />
GRUB\<br />
<br />
Shell> ls fs0:EFI\GRUB\<br />
grubx64.efi<br />
<br />
Shell> fs0:EFI\GRUB\grubx64.efi<br />
Starting fs0:EFI\GRUB\grubx64.efi...<br />
<br />
To prevent this happening again, you can install your bootloader to the default EFI boot location. In this setup, EFI will always find your bootloader on this drive since it is in the default location, which doesn't depend on the EFIVARS being correct. Your system should continue to boot even if another OS has changed the EFIVARS, or your hardware configuration has made the EFIVARS no longer correct for your system.<br />
<br />
To do this with GRUB's {{ic|grub-install}}, use the {{ic|--removable}} flag. For example (update {{ic|/boot/}} to be the path to your EFI partition):<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=/boot/ --bootloader-id=GRUB --removable<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [https://www.uefi.org/home/ UEFI Forum] - contains the official [https://uefi.org/specifications UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
* [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? - A blog post by AdamW]<br />
* [https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txt Linux Kernel x86_64 UEFI Documentation]<br />
* [https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html Intel's page on EFI]<br />
* [https://firmware.intel.com/ Intel Architecture Firmware Resource Center]<br />
* [https://firmware.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]<br />
* [https://firmware.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux]<br />
* [https://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: A Quick Installation Guide]<br />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<br />
* [https://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]<br />
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]<br />
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]<br />
* [https://www.tianocore.org/ Intel's TianoCore Project] for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox<br />
* [https://jdebp.eu/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
* [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq Microsoft's Windows and GPT FAQ]<br />
* [https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/wikis/Windows_x64_BIOS_to_UEFI Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
* [https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/wikis/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
* [https://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
* [https://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]<br />
* [https://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel Documentation]<br />
* [https://web.archive.org/web/20130929114218/http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=584001Unified Extensible Firmware Interface2019-09-27T15:16:47Z<p>ColdPie: /* System boots to EFI shell after hardware change or starting other operating system */ Add example for how to boot an OS from the EFI shell</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:Unified Extensible Firmware Interface]]<br />
[[it:Unified Extensible Firmware Interface]]<br />
[[ja:Unified Extensible Firmware Interface]]<br />
[[ru:Unified Extensible Firmware Interface]]<br />
[[zh-hans:Unified Extensible Firmware Interface]]<br />
{{Related articles start}}<br />
{{Related|EFI system partition}}<br />
{{Related|Arch boot process}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Secure Boot}}<br />
{{Related articles end}}<br />
{{Warning|While the choice to install in UEFI mode is forward looking, early vendor UEFI implementations ''may'' carry more bugs than their BIOS counterparts. It is advised to do a search relating to your particular motherboard model before proceeding.}}<br />
<br />
The [https://www.uefi.org/ Unified Extensible Firmware Interface] (UEFI or EFI for short) is a new model for the interface between operating systems and firmware. It provides a standard environment for booting an operating system and running pre-boot applications.<br />
<br />
It is distinct from the commonly used "[[Partitioning#Master Boot Record (bootstrap code)|MBR boot code]]" method followed for [[Wikipedia:BIOS|BIOS]] systems. See [[Arch boot process]] for their differences and the boot process using UEFI. To set up UEFI boot loaders, see [[Arch boot process#Boot loader]].<br />
<br />
== UEFI versions ==<br />
<br />
* UEFI started as Intel's EFI in versions 1.x.<br />
* Later, a group of companies called the UEFI Forum took over its development, which renamed it as Unified EFI starting with version 2.0.<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware.<br />
* Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one (U)EFI specification and therefore is not a standard UEFI firmware. Unless stated explicitly, these instructions are general and some of them may not work or may be different in [[MacBook|Apple Macs]].<br />
<br />
The latest UEFI specification can be found at https://uefi.org/specifications.<br />
<br />
== UEFI firmware bitness ==<br />
<br />
Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a EFI application corresponding to the UEFI firmware bitness/architecture.<br />
<br />
The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 UEFI firmware. The only known devices that use IA32 (32-bit) UEFI are older (pre 2008) Apple Macs, Intel Atom System-on-Chip systems (as on 2 November 2013)[https://software.intel.com/en-us/blogs/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems] and some older Intel server boards that are known to operate on Intel EFI 1.10 firmware.<br />
<br />
An x86_64 UEFI firmware does not include support for launching 32-bit EFI applications (unlike x86_64 Linux and Windows versions which include such support). Therefore the EFI application must be compiled for that specific firmware processor bitness/architecture.<br />
<br />
{{Note|The official ISO does not support booting on 32-bit (IA32) UEFI systems, see [[#Booting 64-bit kernel on 32-bit UEFI]] for available workarounds. The installed system will require using a boot loader that supports IA32 UEFI, for example, [[GRUB]] with the {{ic|i386-efi}} target.}}<br />
<br />
=== Checking the firmware bitness ===<br />
<br />
The firmware bitness can be checked from a booted operating system.<br />
<br />
==== From Linux ====<br />
<br />
On distributions running Linux kernel 4.0 or newer, the UEFI firmware bitness can be found via the sysfs interface. Run:<br />
<br />
$ cat /sys/firmware/efi/fw_platform_size<br />
<br />
It will return {{ic|64}} for a 64-bit (x86_64) UEFI or {{ic|32}} for a 32-bit (IA32) UEFI. If the file does not exist, then you have not booted in UEFI mode.<br />
<br />
==== From macOS ====<br />
<br />
Pre-2008 [[Mac]]s mostly have IA32 EFI firmware while >=2008 Macs have mostly x86_64 EFI. All Macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware.<br />
<br />
To find out the arch of the EFI firmware in a Mac, type the following into the Mac OS X terminal:<br />
<br />
$ ioreg -l -p IODeviceTree | grep firmware-abi<br />
<br />
If the command returns {{ic|EFI32}} then it is IA32 (32-bit) EFI firmware. If it returns {{ic|EFI64}} then it is x86_64 EFI firmware. Most of the Macs do not have UEFI 2.x firmware as Apple's EFI implementation is not fully compliant with UEFI 2.x specification.<br />
<br />
==== From Microsoft Windows ====<br />
<br />
64-bit versions of Windows do not support booting on a 32-bit UEFI. So, if you have a 32-bit version of Windows booted in UEFI mode, you have a 32-bit UEFI.<br />
<br />
To check the bitness run {{ic|msinfo32.exe}}. In the ''System Summary'' section look at the values of "System Type" and "BIOS mode".<br />
<br />
For a 64-bit Windows on a 64-bit UEFI it will be {{ic|System Type: x64-based PC}} and {{ic|BIOS mode: UEFI}}, for a 32-bit Windows on a 32-bit UEFI - {{ic|System Type: x86-based PC}} and {{ic|BIOS mode: UEFI}}. If the "BIOS mode" is not {{ic|UEFI}}, then Windows is not installed in UEFI mode.<br />
<br />
== Linux kernel config options for UEFI ==<br />
<br />
The required Linux Kernel configuration options[https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txt] for UEFI systems are:<br />
<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_EFI=y<br />
CONFIG_EFI_STUB=y<br />
CONFIG_X86_SYSFB=y<br />
CONFIG_FB_SIMPLE=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
UEFI Runtime Variables Support ('''efivarfs''' filesystem - {{ic|/sys/firmware/efi/efivars}}). This option is important as this is required to manipulate UEFI runtime variables using tools like {{ic|/usr/bin/efibootmgr}}. The below config option has been added in kernel 3.10 and above.<br />
<br />
CONFIG_EFIVAR_FS=y<br />
<br />
UEFI Runtime Variables Support (old '''efivars sysfs''' interface - {{ic|/sys/firmware/efi/vars}}). This option should be disabled to prevent any potential issues with both efivarfs and sysfs-efivars enabled.<br />
<br />
CONFIG_EFI_VARS=n<br />
<br />
[[GUID Partition Table]] (GPT) config option - mandatory for UEFI support<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
EFI mixed-mode support - to boot a x64_64 kernel on a IA32 UEFI.<br />
<br />
CONFIG_EFI_MIXED=y<br />
<br />
{{Note|All of the above options are enabled in Arch Linux [[kernels]] in the official repositories.}}<br />
<br />
== UEFI variables ==<br />
<br />
UEFI defines variables through which an operating system can interact with the firmware. UEFI boot variables are used by the boot loader and used by the OS only for early system start-up. UEFI runtime variables allow an OS to manage certain settings of the firmware like the UEFI boot manager or managing the keys for UEFI Secure Boot protocol etc. You can get the list using:<br />
<br />
$ efivar --list<br />
<br />
=== UEFI variables support in Linux kernel ===<br />
<br />
Linux kernel exposes UEFI variables data to userspace via '''efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface ({{ic|CONFIG_EFIVAR_FS}}) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - it has no maximum per-variable size limitation and supports UEFI Secure Boot variables. Introduced in kernel 3.8.<br />
<br />
=== Requirements for UEFI variable support ===<br />
<br />
# Kernel should be booted in UEFI mode via [[EFISTUB]] (optionally using a [[boot manager]]) or by a UEFI [[boot loader]] (using either the EFI handover protocol or the UEFI LoadImage function), not via BIOS or CSM, or Apple's Boot Camp which is also a CSM.<br />
# EFI Runtime Services support should be present in the kernel ({{ic|1=CONFIG_EFI=y}}, check if present with {{ic|zgrep CONFIG_EFI /proc/config.gz}}).<br />
# EFI Runtime Services in the kernel SHOULD NOT be disabled via kernel cmdline, i.e. {{ic|noefi}} kernel parameter SHOULD NOT be used.<br />
# {{ic|efivarfs}} filesystem should be mounted at {{ic|/sys/firmware/efi/efivars}}, otherwise follow [[#Mount efivarfs]] section below.<br />
# {{ic|efivar}} should list (option {{ic|-l}}/{{ic|--list}}) the UEFI variables without any error.<br />
<br />
If UEFI Variables support does not work even after the above conditions are satisfied, try the below workarounds:<br />
<br />
# If any userspace tool is unable to modify UEFI variable data, check for existence of {{ic|/sys/firmware/efi/efivars/dump-*}} files. If they exist, delete them, reboot and retry again.<br />
# If the above step does not fix the issue, try booting with {{ic|efi_no_storage_paranoia}} kernel parameter to disable kernel UEFI variable storage space check that may prevent writing/modification of UEFI variables.<br />
<br />
{{Warning|{{ic|efi_no_storage_paranoia}} should only be used when needed and should not be left as a normal boot option. The effect of this kernel command line parameter turns off a safeguard that was put in place to help avoid the bricking of machines when the NVRAM gets too full. See {{Bug|34641}} for more information.}}<br />
<br />
==== Mount efivarfs ====<br />
<br />
If {{ic|efivarfs}} is not automatically mounted at {{ic|/sys/firmware/efi/efivars}} by [[systemd]] during boot, then you need to manually mount it to expose UEFI variables to [[#Userspace tools|userspace tools]] like ''efibootmgr'':<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both '''outside''' ('''before''') and '''inside''' the [[chroot]], if any.}}<br />
<br />
See [https://www.kernel.org/doc/Documentation/filesystems/efivarfs.txt efivarfs.txt] for kernel documentation.<br />
<br />
=== Userspace tools ===<br />
<br />
There are few tools that can access/modify the UEFI variables, namely<br />
<br />
* {{App|efivar|Library and Tool to manipulate UEFI variables (used by efibootmgr)|https://github.com/rhboot/efivar|{{Pkg|efivar}}, {{AUR|efivar-git}}}}<br />
* {{App|efibootmgr|Tool to manipulate UEFI Firmware Boot Manager Settings|https://github.com/rhboot/efibootmgr|{{Pkg|efibootmgr}}}}<br />
* {{App|uefivars|Dumps list of UEFI variables with some additional PCI related info (uses efibootmgr code internally)|https://github.com/fpmurphy/Various/tree/master/uefivars-2.0|{{AUR|uefivars-git}}}}<br />
* {{App|efitools|Tools for manipulating UEFI secure boot platforms|https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git|{{Pkg|efitools}}}}<br />
* {{App|Ubuntu's Firmware Test Suite|Test suite that performs sanity checks on Intel/AMD PC firmware|https://wiki.ubuntu.com/FirmwareTestSuite/|{{AUR|fwts-git}}}}<br />
<br />
==== efibootmgr ====<br />
<br />
You will have to [[install]] the {{Pkg|efibootmgr}} package.<br />
<br />
{{Note|<br />
* If ''efibootmgr'' does not work on your system, you can reboot into [[#UEFI Shell]] and use {{ic|bcfg}} to create a boot entry for the bootloader.<br />
* If you are unable to use {{ic|efibootmgr}}, some UEFI firmwares allow users to directly manage UEFI boot entries from within its boot-time interface. For example, some firmwares have an "Add New Boot Option" choice which enables you to select a local EFI system partition and manually enter the EFI application location e.g. {{ic|\EFI\refind\refind_x64.efi}}.<br />
* The below commands use [[rEFInd]] boot manager as example.<br />
}}<br />
<br />
To add a new boot option using ''efibootmgr'' you need to know three things:<br />
<br />
# The disk containing the [[EFI system partition]] (ESP). E.g.: {{ic|/dev/sda}}, {{ic|/dev/nvme0n1}}.<br />
# The partition number of the ESP on that disk. The {{ic|''Y''}} in {{ic|/dev/sda''Y''}} or {{ic|/dev/nvme0n1p''Y''}}.<br />
# The path to the EFI application (relative to the root of the ESP)<br />
<br />
For example, if you want to add a boot option for {{ic|/efi/EFI/refind/refind_x64.efi}} where {{ic|/efi}} is the mount point of the ESP, run<br />
<br />
{{hc|$ findmnt /efi|2=<br />
TARGET SOURCE FSTYPE OPTIONS<br />
/efi /dev/sda1 vfat rw,flush,tz=UTC<br />
}}<br />
<br />
In this example, this indicates that the ESP is on disk {{ic|/dev/sda}} and has partition number 1. The path to the EFI application relative to the root of the ESP is {{ic|/EFI/refind/refind_x64.efi}}. So you would create the boot entry as follows:<br />
<br />
# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose<br />
<br />
{{Accuracy|{{ic|/dev/nvme0n1p1}} is a partition not a disk, the partition number should be specified using the {{ic|--part}} option.}}<br />
<br />
# efibootmgr --create --disk /dev/nvme0n1p1 --loader /EFI/refind/refind_x64.efi --label "rEFINd Boot Manager" --verbose<br />
<br />
See {{man|8|efibootmgr}} or [https://raw.githubusercontent.com/rhinstaller/efibootmgr/master/README efibootmgr README] for more info.<br />
<br />
{{Note|UEFI uses backward slash {{ic|\}} as path separator but ''efibootmgr'' automatically converts UNIX-style {{ic|/}} path separators.}}<br />
<br />
== UEFI Shell ==<br />
<br />
The UEFI Shell is a shell/terminal for the firmware which allows launching EFI applications which include UEFI bootloaders. Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), modifying boot manager variables (bcfg), running partitioning programs (diskpart), loading UEFI drivers, editing text files (edit), hexedit etc.<br />
<br />
=== Obtaining UEFI Shell ===<br />
<br />
You can download a BSD licensed UEFI Shell from Intel's TianoCore UDK/EDK2 project:<br />
<br />
* [[AUR]] package {{AUR|uefi-shell-git}} (recommended) - provides x86_64 Shell for x86_64 (64-bit) UEFI and IA32 Shell for IA32 (32-bit) UEFI - compiled directly from latest TianoCore EDK2 source.<br />
* There are copies of Shell v1 and Shell v2 in the EFI directory on the Arch install media image.<br />
* [https://github.com/tianocore/edk2/releases/latest/download/ShellBinPkg.zip Precompiled UEFI Shell v2 binaries] (the binary package was moved from its original location in the source tree to the GitHub release assets, as laid out [https://lists.01.org/pipermail/edk2-devel/2019-April/thread.html#38524 here]).<br />
* [https://github.com/tianocore/edk2/tree/UDK2018/EdkShellBinPkg Precompiled UEFI Shell v1 binaries] (not updated anymore upstream as of Jan 10, 2014).<br />
* [https://drive.google.com/uc?export=download&id=1OBXYj6MEs7VAZbYnjD9FxOYcZYIQoq36 Precompiled UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware] - from Clover EFI bootloader.<br />
<br />
Shell v2 works best in UEFI 2.3+ systems and is recommended over Shell v1 in those systems. Shell v1 should work in all UEFI systems irrespective of the spec. version the firmware follows. More info at [https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg ShellPkg] and [https://edk2-devel.narkive.com/zCN4CEnb/inclusion-of-uefi-shell-in-linux-distro-iso this mail].<br />
<br />
=== Launching UEFI Shell ===<br />
<br />
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called {{ic|"Launch EFI Shell from filesystem device"}} . For those motherboards, download the x86_64 UEFI Shell and copy it to your EFI system partition as {{ic|<EFI_SYSTEM_PARTITION>/shellx64.efi}}.<br />
<br />
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either {{ic|F6}}, {{ic|F11}} or {{ic|F12}} key.<br />
<br />
{{Note|If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a [[FAT32]] USB pen drive with {{ic|Shell.efi}} copied as {{ic|(USB)/EFI/BOOT/BOOTx64.EFI}}. This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.}}<br />
<br />
=== Important UEFI Shell commands ===<br />
<br />
UEFI Shell commands usually support {{ic|-b}} option which makes output pause after each page. Run {{ic|help -b}} to list available internal commands. Available commands are either built into the shell or discrete EFI applications.<br />
<br />
For more info see [https://software.intel.com/en-us/articles/efi-shells-and-scripting/ Intel Scripting Guide 2008] and [https://software.intel.com/en-us/articles/uefi-shell Intel "Course" 2011].<br />
<br />
==== bcfg ====<br />
<br />
{{ic|bcfg}} modifies the UEFI NVRAM entries which allows the user to change the boot entries or driver options. This command is described in detail in page 96 (Section 5.3) of the [https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf UEFI Shell Specification 2.2] document.<br />
<br />
{{Note|<br />
* Try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries on your system.<br />
* UEFI Shell v1 official binary does not support {{ic|bcfg}} command. See [[#Obtaining UEFI Shell]] for a modified UEFI Shell v2 binary which may work in UEFI pre-2.3 firmwares.<br />
}}<br />
<br />
To dump a list of current boot entries:<br />
<br />
Shell> bcfg boot dump -v<br />
<br />
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu:<br />
<br />
Shell> bcfg boot add 3 FS0:\EFI\refind\refind_x64.efi "rEFInd"<br />
<br />
where {{ic|FS0:}} is the mapping corresponding to the EFI system partition and {{ic|FS0:\EFI\refind\refind_x64.efi}} is the file to be launched.<br />
<br />
To add an entry to boot directly into your system without a bootloader, configure a boot option using your kernel as an [[EFISTUB#UEFI_Shell|EFISTUB]]:<br />
<br />
Shell> bcfg boot add '''N''' fs'''V''':\vmlinuz-linux "Arch Linux"<br />
Shell> bcfg boot -opt '''N''' "root='''/dev/sdX#''' initrd=\initramfs-linux.img"<br />
<br />
where {{ic|N}} is the priority, {{ic|V}} is the volume number of your EFI system partition, and {{ic|/dev/sdX#}} is your root partition.<br />
<br />
To remove the 4th boot option:<br />
<br />
Shell> bcfg boot rm 3<br />
<br />
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu):<br />
<br />
Shell> bcfg boot mv 3 0<br />
<br />
For bcfg help text:<br />
<br />
Shell> help bcfg -v -b<br />
<br />
or:<br />
<br />
Shell> bcfg -? -v -b<br />
<br />
==== map ====<br />
<br />
{{ic|map}} displays a list of device mappings i.e. the names of available file systems ({{ic|FS0}}) and storage devices ({{ic|blk0}}).<br />
<br />
Before running file system commands such as {{ic|cd}} or {{ic|ls}}, you need to change the shell to the appropriate file system by typing its name:<br />
<br />
Shell> FS0:<br />
FS0:\> cd EFI/<br />
<br />
==== edit ====<br />
<br />
{{ic|edit}} provides a basic text editor with an interface similar to nano, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
For example, to edit rEFInd's {{ic|refind.conf}} in the EFI system partition ({{ic|FS0:}} in the firmware),<br />
<br />
Shell> edit FS0:\EFI\refind\refind.conf<br />
<br />
Type {{ic|Ctrl-E}} for help.<br />
<br />
== UEFI drivers ==<br />
<br />
{{Expansion|Explain what are and how to use UEFI drivers.}}<br />
<br />
== UEFI bootable media ==<br />
<br />
=== Create UEFI bootable USB from ISO ===<br />
<br />
Follow [[USB flash installation media#BIOS and UEFI bootable USB]].<br />
<br />
=== Remove UEFI boot support from optical media ===<br />
<br />
{{Note|<br />
* This section mentions removing UEFI boot support from a '''CD/DVD only''' (Optical Media booting via EL Torito), not from a USB flash drive.<br />
* In order to hide the UEFI equipment on USB stick, use a partition editor after having copied the ISO to the flash drive. Remove the partition of type {{ic|EF}}. '''Do not''' accept offers to convert to GPT.<br />
}}<br />
<br />
Most of the 32-bit EFI Macs and some 64-bit EFI Macs refuse to boot from a UEFI(X64)+BIOS bootable CD/DVD. If one wishes to proceed with the installation using optical media, it might be necessary to remove UEFI support first.<br />
<br />
* Mount the official installation media and obtain the {{ic|archisolabel}} as shown in the previous section.<br />
<br />
# mount -o loop ''input.iso'' /mnt/iso<br />
<br />
* Then rebuild the ISO, excluding the UEFI optical media booting support, using {{ic|xorriso}} from {{pkg|libisoburn}}. Be sure to set the correct archisolabel, e.g. "ARCH_201411" or similar:<br />
<br />
{{bc|1=<br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "''archisolabel''" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared by $USER" \<br />
-eltorito-boot isolinux/isolinux.bin \<br />
-eltorito-catalog isolinux/boot.cat \<br />
-no-emul-boot -boot-load-size 4 -boot-info-table \<br />
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \<br />
-output ''output.iso'' /mnt/iso/<br />
}}<br />
<br />
* Burn {{ic|''output.iso''}} to optical media and proceed with installation normally.<br />
<br />
=== Booting 64-bit kernel on 32-bit UEFI ===<br />
<br />
Official ISO ([[Archiso]]) does not support booting on 32-bit (IA32) UEFI systems ({{Bug|53182}}) since it uses EFISTUB (via [[systemd-boot]] boot manager for menu) for booting the kernel in UEFI mode. To boot a 64-bit kernel with 32-bit UEFI you have to use a boot loader that does not rely on EFI boot stub for launching kernels.<br />
<br />
{{Tip|[[Archboot]] iso supports booting on 32-bit (IA32) UEFI systems.}}<br />
<br />
==== Using GRUB ====<br />
<br />
This section describes how to setup [[GRUB]] as the USB's UEFI bootloader.<br />
<br />
* [[USB flash installation media#Using_manual_formatting|Create an editable USB Flash Installation]]. Since we are going to use GRUB, you only need to follow the steps up until the {{ic|syslinux}} part<br />
<br />
* [[GRUB/Tips and tricks#GRUB standalone|Create a GRUB standalone image]] for 32-bit UEFI systems:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg<br />
# grub-mkstandalone -d /usr/lib/grub/i386-efi -O i386-efi --modules="part_gpt part_msdos" --locales="en@quot" --themes="" -o "''/mnt/usb/''EFI/boot/bootia32.efi" "boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
* Create {{ic|''/mnt/usb''/EFI/boot/grub.cfg}} with the following contents (replace {{ic|ARCH_YYYYMM}} with the required archiso label e.g. {{ic|ARCH_201507}}):<br />
<br />
{{Tip|<br />
* The archiso label can be aquired from the ''.iso'' file with {{ic|isoinfo}} from {{Pkg|cdrtools}} or {{ic|iso-info}} from {{Pkg|libcdio}}.<br />
* The given configuration entries can also be entered inside a [[GRUB#Using_the_command_shell|GRUB command-shell]].<br />
}}<br />
<br />
For the official ISO:<br />
<br />
{{hc|''/mnt/usb''/EFI/boot/grub.cfg|2=<br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux archiso x86_64 UEFI USB" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --label ''ARCH_YYYYMM''<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=''ARCH_YYYYMM'' add_efi_memmap<br />
initrd /arch/boot/intel_ucode.img /arch/boot/x86_64/archiso.img<br />
}<br />
}}<br />
<br />
Durring installation, in the [[Installation guide#Boot loader|boot loader installation step]], [[GRUB#Installation_2|install GRUB]] using the option {{ic|1=--target=i386-efi}}.<br />
<br />
== Testing UEFI in systems without native support ==<br />
<br />
=== OVMF for virtual machines ===<br />
<br />
[https://tianocore.github.io/ovmf/ OVMF] is a TianoCore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware and a separate non-volatile variable store for QEMU.<br />
<br />
You can install {{pkg|ovmf}} from the extra repository.<br />
<br />
It is [https://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt advised] to make a local copy of the non-volatile variable store for your virtual machine:<br />
<br />
$ cp /usr/share/ovmf/x64/OVMF_VARS.fd my_uefi_vars.bin<br />
<br />
To use the OVMF firmware and this variable store, add following to your QEMU command:<br />
<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd \<br />
-drive if=pflash,format=raw,file=my_uefi_vars.bin<br />
<br />
For example:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd -drive if=pflash,format=raw,file=my_uefi_vars.bin …<br />
<br />
=== DUET for BIOS only systems ===<br />
<br />
DUET was a TianoCore project that enabled chainloading a full UEFI environment from a BIOS system, in a way similar to BIOS OS booting. This method is being discussed extensively in https://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/. Pre-build DUET images can be downloaded from one of the repos at https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer. Specific instructions for setting up DUET is available at https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blob/master/Migle_BootDuet_INSTALL.txt . However, as of November 2018, the DUET code has been removed from TianoCore git repository.<br />
<br />
You can also try https://sourceforge.net/projects/cloverefiboot/ which provides modified DUET images that may contain some system specific fixes and is more frequently updated compared to the gitlab repos.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Windows 7 will not boot in UEFI mode ===<br />
<br />
{{Note|Windows 7 can boot in pure UEFI class 3 without CSM support, though installation requires CSM ([https://support.microsoft.com/en-us/kb/2828074 specifically INT 10 H]).}}<br />
<br />
If you have installed Windows to a different hard disk with GPT partitioning and still have a MBR partitioned hard disk in your computer, then it is possible that the firmware (UEFI) is starting its CSM support (for booting MBR partitions) and therefore Windows will not boot. To solve this merge your MBR hard disk to GPT partitioning or disable the SATA port where the MBR hard disk is plugged in or unplug the SATA connector from this hard disk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
* Gigabyte Z77X-UD3H rev. 1.1 (UEFI version F19e)<br />
** The firmware option for booting "UEFI Only" does not prevent the firmware from starting CSM.<br />
<br />
=== Windows changes boot order ===<br />
<br />
If you [[dual boot with Windows]] and your motherboard just boots Windows immediately instead of your chosen EFI application, there are several possible causes and workarounds.<br />
<br />
* Ensure [[Dual boot with Windows#Fast_Start-Up|Fast Startup]] is disabled in your Windows power options<br />
* Ensure [[Secure Boot]] is disabled in your BIOS (if you are not using a signed boot loader)<br />
* Ensure your UEFI boot order does not have Windows Boot Manager set first e.g. using [[#efibootmgr]] and what you see in the configuration tool of the UEFI. Some motherboards override by default any settings set with efibootmgr by Windows if it detects it. This is confirmed in a Packard Bell laptop.<br />
* If your motherboard is booting the default boot path ({{ic|\EFI\BOOT\BOOTX64.EFI}}), this file may have been overwritten with the Windows boot loader. Try setting the correct boot path e.g. using [[#efibootmgr]].<br />
* If the previous steps do not work, you can tell the Windows boot loader to run a different EFI application. From a Windows Administrator command prompt: {{bc|# bcdedit /set "{bootmgr}" path "\EFI\''path''\''to''\''app.efi''"}}<br />
* Alternatively, you can set a startup script in Windows that ensures that the boot order is set correctly every time you boot Windows.<br />
*# Open a command prompt with admin privlages. Run {{ic|bcdedit /enum firmware}} and find your desired boot entry.<br />
*# Copy the Identifier, including the brackets, e.g. {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}<br />
*# Create a batch file with the command {{ic|bcdedit /set "{fwbootmgr}" DEFAULT "{''copied boot identifier''}"}}<br />
*# Open ''gpedit.msc'' and under ''Local Computer Policy > Computer Configuration > Windows Settings > Scripts(Startup/Shutdown)'', choose ''Startup''<br />
*# Under the ''Scripts'' tab, choose the ''Add'' button, and select your batch file<br />
<br />
=== USB media gets struck with black screen ===<br />
<br />
This issue can occur due to [[KMS]] issue. Try [[Kernel mode setting#Disabling_modesetting|Disabling KMS]] while booting the USB.<br />
<br />
=== UEFI boot loader does not show up in firmware menu ===<br />
<br />
On certain UEFI motherboards like some boards with an Intel Z77 chipset, adding entries with {{ic|efibootmgr}} or {{ic|bcfg}} from the UEFI Shell will not work because they do not show up on the boot menu list after being added to NVRAM.<br />
<br />
This issue is caused because the motherboards can only load Microsoft Windows. To solve this you have to place the ''.efi'' file in the location that Windows uses.<br />
<br />
Copy the {{ic|bootx64.efi}} file from the Arch Linux installation medium ({{ic|FSO:}}) to the Microsoft directory your [[ESP]] partition on your hard drive ({{ic|FS1:}}). Do this by booting into EFI shell and typing:<br />
<br />
Shell> mkdir FS1:\EFI\Microsoft<br />
Shell> mkdir FS1:\EFI\Microsoft\Boot<br />
Shell> cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi<br />
<br />
After reboot, any entries added to NVRAM should show up in the boot menu.<br />
<br />
=== System boots to EFI shell after hardware change or starting other operating system ===<br />
<br />
EFI stores state on the motherboard, called EFIVARS. Your bootloader (e.g. GRUB) may need to set up these variables in a certain way in order to boot. If your hardware configuration changes, or you boot into another operating system which overwrites these variables (Windows), you may be dumped into the EFI shell upon attempting to boot Arch Linux since the EFIVARS are incorrect and EFI can no longer find your bootloader.<br />
<br />
At this point, you can use the EFI shell to find and boot your bootloader manually. Usually something like:<br />
<br />
Shell> ls fs0:<br />
EFI\<br />
grub\<br />
<br />
Shell> ls fs0:EFI\<br />
GRUB\<br />
<br />
Shell> ls fs0:EFI\GRUB\<br />
grubx64.efi<br />
<br />
Shell> fs0:EFI\GRUB\grubx64.efi<br />
Starting fs0:EFI\GRUB\grubx64.efi...<br />
<br />
To prevent this happening again, you can install GRUB to the default EFI boot location. In this setup, EFI will always find your bootloader on this drive since it is in the default location, which doesn't depend on the EFIVARS being correct. Your system should continue to boot even if another OS has changed the EFIVARS, or your hardware configuration has made the EFIVARS no longer correct for your system.<br />
<br />
To do this with {{ic|grub-install}}, use the {{ic|--removable}} flag. For example (update {{ic|/boot/}} to be the path to your EFI partition):<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=/boot/ --bootloader-id=GRUB --removable<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [https://www.uefi.org/home/ UEFI Forum] - contains the official [https://uefi.org/specifications UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
* [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? - A blog post by AdamW]<br />
* [https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txt Linux Kernel x86_64 UEFI Documentation]<br />
* [https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html Intel's page on EFI]<br />
* [https://firmware.intel.com/ Intel Architecture Firmware Resource Center]<br />
* [https://firmware.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]<br />
* [https://firmware.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux]<br />
* [https://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: A Quick Installation Guide]<br />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<br />
* [https://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]<br />
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]<br />
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]<br />
* [https://www.tianocore.org/ Intel's TianoCore Project] for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox<br />
* [https://jdebp.eu/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
* [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq Microsoft's Windows and GPT FAQ]<br />
* [https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/wikis/Windows_x64_BIOS_to_UEFI Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
* [https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/wikis/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
* [https://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
* [https://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]<br />
* [https://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel Documentation]<br />
* [https://web.archive.org/web/20130929114218/http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=584000Unified Extensible Firmware Interface2019-09-27T15:12:42Z<p>ColdPie: /* Troubleshooting */ Add section about --removable flag for grub-install</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:Unified Extensible Firmware Interface]]<br />
[[it:Unified Extensible Firmware Interface]]<br />
[[ja:Unified Extensible Firmware Interface]]<br />
[[ru:Unified Extensible Firmware Interface]]<br />
[[zh-hans:Unified Extensible Firmware Interface]]<br />
{{Related articles start}}<br />
{{Related|EFI system partition}}<br />
{{Related|Arch boot process}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Secure Boot}}<br />
{{Related articles end}}<br />
{{Warning|While the choice to install in UEFI mode is forward looking, early vendor UEFI implementations ''may'' carry more bugs than their BIOS counterparts. It is advised to do a search relating to your particular motherboard model before proceeding.}}<br />
<br />
The [https://www.uefi.org/ Unified Extensible Firmware Interface] (UEFI or EFI for short) is a new model for the interface between operating systems and firmware. It provides a standard environment for booting an operating system and running pre-boot applications.<br />
<br />
It is distinct from the commonly used "[[Partitioning#Master Boot Record (bootstrap code)|MBR boot code]]" method followed for [[Wikipedia:BIOS|BIOS]] systems. See [[Arch boot process]] for their differences and the boot process using UEFI. To set up UEFI boot loaders, see [[Arch boot process#Boot loader]].<br />
<br />
== UEFI versions ==<br />
<br />
* UEFI started as Intel's EFI in versions 1.x.<br />
* Later, a group of companies called the UEFI Forum took over its development, which renamed it as Unified EFI starting with version 2.0.<br />
* Unless specified as EFI 1.x, EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware.<br />
* Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one (U)EFI specification and therefore is not a standard UEFI firmware. Unless stated explicitly, these instructions are general and some of them may not work or may be different in [[MacBook|Apple Macs]].<br />
<br />
The latest UEFI specification can be found at https://uefi.org/specifications.<br />
<br />
== UEFI firmware bitness ==<br />
<br />
Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a EFI application corresponding to the UEFI firmware bitness/architecture.<br />
<br />
The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 UEFI firmware. The only known devices that use IA32 (32-bit) UEFI are older (pre 2008) Apple Macs, Intel Atom System-on-Chip systems (as on 2 November 2013)[https://software.intel.com/en-us/blogs/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems] and some older Intel server boards that are known to operate on Intel EFI 1.10 firmware.<br />
<br />
An x86_64 UEFI firmware does not include support for launching 32-bit EFI applications (unlike x86_64 Linux and Windows versions which include such support). Therefore the EFI application must be compiled for that specific firmware processor bitness/architecture.<br />
<br />
{{Note|The official ISO does not support booting on 32-bit (IA32) UEFI systems, see [[#Booting 64-bit kernel on 32-bit UEFI]] for available workarounds. The installed system will require using a boot loader that supports IA32 UEFI, for example, [[GRUB]] with the {{ic|i386-efi}} target.}}<br />
<br />
=== Checking the firmware bitness ===<br />
<br />
The firmware bitness can be checked from a booted operating system.<br />
<br />
==== From Linux ====<br />
<br />
On distributions running Linux kernel 4.0 or newer, the UEFI firmware bitness can be found via the sysfs interface. Run:<br />
<br />
$ cat /sys/firmware/efi/fw_platform_size<br />
<br />
It will return {{ic|64}} for a 64-bit (x86_64) UEFI or {{ic|32}} for a 32-bit (IA32) UEFI. If the file does not exist, then you have not booted in UEFI mode.<br />
<br />
==== From macOS ====<br />
<br />
Pre-2008 [[Mac]]s mostly have IA32 EFI firmware while >=2008 Macs have mostly x86_64 EFI. All Macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware.<br />
<br />
To find out the arch of the EFI firmware in a Mac, type the following into the Mac OS X terminal:<br />
<br />
$ ioreg -l -p IODeviceTree | grep firmware-abi<br />
<br />
If the command returns {{ic|EFI32}} then it is IA32 (32-bit) EFI firmware. If it returns {{ic|EFI64}} then it is x86_64 EFI firmware. Most of the Macs do not have UEFI 2.x firmware as Apple's EFI implementation is not fully compliant with UEFI 2.x specification.<br />
<br />
==== From Microsoft Windows ====<br />
<br />
64-bit versions of Windows do not support booting on a 32-bit UEFI. So, if you have a 32-bit version of Windows booted in UEFI mode, you have a 32-bit UEFI.<br />
<br />
To check the bitness run {{ic|msinfo32.exe}}. In the ''System Summary'' section look at the values of "System Type" and "BIOS mode".<br />
<br />
For a 64-bit Windows on a 64-bit UEFI it will be {{ic|System Type: x64-based PC}} and {{ic|BIOS mode: UEFI}}, for a 32-bit Windows on a 32-bit UEFI - {{ic|System Type: x86-based PC}} and {{ic|BIOS mode: UEFI}}. If the "BIOS mode" is not {{ic|UEFI}}, then Windows is not installed in UEFI mode.<br />
<br />
== Linux kernel config options for UEFI ==<br />
<br />
The required Linux Kernel configuration options[https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txt] for UEFI systems are:<br />
<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_EFI=y<br />
CONFIG_EFI_STUB=y<br />
CONFIG_X86_SYSFB=y<br />
CONFIG_FB_SIMPLE=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
UEFI Runtime Variables Support ('''efivarfs''' filesystem - {{ic|/sys/firmware/efi/efivars}}). This option is important as this is required to manipulate UEFI runtime variables using tools like {{ic|/usr/bin/efibootmgr}}. The below config option has been added in kernel 3.10 and above.<br />
<br />
CONFIG_EFIVAR_FS=y<br />
<br />
UEFI Runtime Variables Support (old '''efivars sysfs''' interface - {{ic|/sys/firmware/efi/vars}}). This option should be disabled to prevent any potential issues with both efivarfs and sysfs-efivars enabled.<br />
<br />
CONFIG_EFI_VARS=n<br />
<br />
[[GUID Partition Table]] (GPT) config option - mandatory for UEFI support<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
EFI mixed-mode support - to boot a x64_64 kernel on a IA32 UEFI.<br />
<br />
CONFIG_EFI_MIXED=y<br />
<br />
{{Note|All of the above options are enabled in Arch Linux [[kernels]] in the official repositories.}}<br />
<br />
== UEFI variables ==<br />
<br />
UEFI defines variables through which an operating system can interact with the firmware. UEFI boot variables are used by the boot loader and used by the OS only for early system start-up. UEFI runtime variables allow an OS to manage certain settings of the firmware like the UEFI boot manager or managing the keys for UEFI Secure Boot protocol etc. You can get the list using:<br />
<br />
$ efivar --list<br />
<br />
=== UEFI variables support in Linux kernel ===<br />
<br />
Linux kernel exposes UEFI variables data to userspace via '''efivarfs''' ('''EFI''' '''VAR'''iable '''F'''ile'''S'''ystem) interface ({{ic|CONFIG_EFIVAR_FS}}) - mounted using {{ic|efivarfs}} kernel module at {{ic|/sys/firmware/efi/efivars}} - it has no maximum per-variable size limitation and supports UEFI Secure Boot variables. Introduced in kernel 3.8.<br />
<br />
=== Requirements for UEFI variable support ===<br />
<br />
# Kernel should be booted in UEFI mode via [[EFISTUB]] (optionally using a [[boot manager]]) or by a UEFI [[boot loader]] (using either the EFI handover protocol or the UEFI LoadImage function), not via BIOS or CSM, or Apple's Boot Camp which is also a CSM.<br />
# EFI Runtime Services support should be present in the kernel ({{ic|1=CONFIG_EFI=y}}, check if present with {{ic|zgrep CONFIG_EFI /proc/config.gz}}).<br />
# EFI Runtime Services in the kernel SHOULD NOT be disabled via kernel cmdline, i.e. {{ic|noefi}} kernel parameter SHOULD NOT be used.<br />
# {{ic|efivarfs}} filesystem should be mounted at {{ic|/sys/firmware/efi/efivars}}, otherwise follow [[#Mount efivarfs]] section below.<br />
# {{ic|efivar}} should list (option {{ic|-l}}/{{ic|--list}}) the UEFI variables without any error.<br />
<br />
If UEFI Variables support does not work even after the above conditions are satisfied, try the below workarounds:<br />
<br />
# If any userspace tool is unable to modify UEFI variable data, check for existence of {{ic|/sys/firmware/efi/efivars/dump-*}} files. If they exist, delete them, reboot and retry again.<br />
# If the above step does not fix the issue, try booting with {{ic|efi_no_storage_paranoia}} kernel parameter to disable kernel UEFI variable storage space check that may prevent writing/modification of UEFI variables.<br />
<br />
{{Warning|{{ic|efi_no_storage_paranoia}} should only be used when needed and should not be left as a normal boot option. The effect of this kernel command line parameter turns off a safeguard that was put in place to help avoid the bricking of machines when the NVRAM gets too full. See {{Bug|34641}} for more information.}}<br />
<br />
==== Mount efivarfs ====<br />
<br />
If {{ic|efivarfs}} is not automatically mounted at {{ic|/sys/firmware/efi/efivars}} by [[systemd]] during boot, then you need to manually mount it to expose UEFI variables to [[#Userspace tools|userspace tools]] like ''efibootmgr'':<br />
<br />
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
<br />
{{Note|The above command should be run both '''outside''' ('''before''') and '''inside''' the [[chroot]], if any.}}<br />
<br />
See [https://www.kernel.org/doc/Documentation/filesystems/efivarfs.txt efivarfs.txt] for kernel documentation.<br />
<br />
=== Userspace tools ===<br />
<br />
There are few tools that can access/modify the UEFI variables, namely<br />
<br />
* {{App|efivar|Library and Tool to manipulate UEFI variables (used by efibootmgr)|https://github.com/rhboot/efivar|{{Pkg|efivar}}, {{AUR|efivar-git}}}}<br />
* {{App|efibootmgr|Tool to manipulate UEFI Firmware Boot Manager Settings|https://github.com/rhboot/efibootmgr|{{Pkg|efibootmgr}}}}<br />
* {{App|uefivars|Dumps list of UEFI variables with some additional PCI related info (uses efibootmgr code internally)|https://github.com/fpmurphy/Various/tree/master/uefivars-2.0|{{AUR|uefivars-git}}}}<br />
* {{App|efitools|Tools for manipulating UEFI secure boot platforms|https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git|{{Pkg|efitools}}}}<br />
* {{App|Ubuntu's Firmware Test Suite|Test suite that performs sanity checks on Intel/AMD PC firmware|https://wiki.ubuntu.com/FirmwareTestSuite/|{{AUR|fwts-git}}}}<br />
<br />
==== efibootmgr ====<br />
<br />
You will have to [[install]] the {{Pkg|efibootmgr}} package.<br />
<br />
{{Note|<br />
* If ''efibootmgr'' does not work on your system, you can reboot into [[#UEFI Shell]] and use {{ic|bcfg}} to create a boot entry for the bootloader.<br />
* If you are unable to use {{ic|efibootmgr}}, some UEFI firmwares allow users to directly manage UEFI boot entries from within its boot-time interface. For example, some firmwares have an "Add New Boot Option" choice which enables you to select a local EFI system partition and manually enter the EFI application location e.g. {{ic|\EFI\refind\refind_x64.efi}}.<br />
* The below commands use [[rEFInd]] boot manager as example.<br />
}}<br />
<br />
To add a new boot option using ''efibootmgr'' you need to know three things:<br />
<br />
# The disk containing the [[EFI system partition]] (ESP). E.g.: {{ic|/dev/sda}}, {{ic|/dev/nvme0n1}}.<br />
# The partition number of the ESP on that disk. The {{ic|''Y''}} in {{ic|/dev/sda''Y''}} or {{ic|/dev/nvme0n1p''Y''}}.<br />
# The path to the EFI application (relative to the root of the ESP)<br />
<br />
For example, if you want to add a boot option for {{ic|/efi/EFI/refind/refind_x64.efi}} where {{ic|/efi}} is the mount point of the ESP, run<br />
<br />
{{hc|$ findmnt /efi|2=<br />
TARGET SOURCE FSTYPE OPTIONS<br />
/efi /dev/sda1 vfat rw,flush,tz=UTC<br />
}}<br />
<br />
In this example, this indicates that the ESP is on disk {{ic|/dev/sda}} and has partition number 1. The path to the EFI application relative to the root of the ESP is {{ic|/EFI/refind/refind_x64.efi}}. So you would create the boot entry as follows:<br />
<br />
# efibootmgr --create --disk /dev/sda --part 1 --loader /EFI/refind/refind_x64.efi --label "rEFInd Boot Manager" --verbose<br />
<br />
{{Accuracy|{{ic|/dev/nvme0n1p1}} is a partition not a disk, the partition number should be specified using the {{ic|--part}} option.}}<br />
<br />
# efibootmgr --create --disk /dev/nvme0n1p1 --loader /EFI/refind/refind_x64.efi --label "rEFINd Boot Manager" --verbose<br />
<br />
See {{man|8|efibootmgr}} or [https://raw.githubusercontent.com/rhinstaller/efibootmgr/master/README efibootmgr README] for more info.<br />
<br />
{{Note|UEFI uses backward slash {{ic|\}} as path separator but ''efibootmgr'' automatically converts UNIX-style {{ic|/}} path separators.}}<br />
<br />
== UEFI Shell ==<br />
<br />
The UEFI Shell is a shell/terminal for the firmware which allows launching EFI applications which include UEFI bootloaders. Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), modifying boot manager variables (bcfg), running partitioning programs (diskpart), loading UEFI drivers, editing text files (edit), hexedit etc.<br />
<br />
=== Obtaining UEFI Shell ===<br />
<br />
You can download a BSD licensed UEFI Shell from Intel's TianoCore UDK/EDK2 project:<br />
<br />
* [[AUR]] package {{AUR|uefi-shell-git}} (recommended) - provides x86_64 Shell for x86_64 (64-bit) UEFI and IA32 Shell for IA32 (32-bit) UEFI - compiled directly from latest TianoCore EDK2 source.<br />
* There are copies of Shell v1 and Shell v2 in the EFI directory on the Arch install media image.<br />
* [https://github.com/tianocore/edk2/releases/latest/download/ShellBinPkg.zip Precompiled UEFI Shell v2 binaries] (the binary package was moved from its original location in the source tree to the GitHub release assets, as laid out [https://lists.01.org/pipermail/edk2-devel/2019-April/thread.html#38524 here]).<br />
* [https://github.com/tianocore/edk2/tree/UDK2018/EdkShellBinPkg Precompiled UEFI Shell v1 binaries] (not updated anymore upstream as of Jan 10, 2014).<br />
* [https://drive.google.com/uc?export=download&id=1OBXYj6MEs7VAZbYnjD9FxOYcZYIQoq36 Precompiled UEFI Shell v2 binary with bcfg modified to work with UEFI pre-2.3 firmware] - from Clover EFI bootloader.<br />
<br />
Shell v2 works best in UEFI 2.3+ systems and is recommended over Shell v1 in those systems. Shell v1 should work in all UEFI systems irrespective of the spec. version the firmware follows. More info at [https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg ShellPkg] and [https://edk2-devel.narkive.com/zCN4CEnb/inclusion-of-uefi-shell-in-linux-distro-iso this mail].<br />
<br />
=== Launching UEFI Shell ===<br />
<br />
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called {{ic|"Launch EFI Shell from filesystem device"}} . For those motherboards, download the x86_64 UEFI Shell and copy it to your EFI system partition as {{ic|<EFI_SYSTEM_PARTITION>/shellx64.efi}}.<br />
<br />
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either {{ic|F6}}, {{ic|F11}} or {{ic|F12}} key.<br />
<br />
{{Note|If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a [[FAT32]] USB pen drive with {{ic|Shell.efi}} copied as {{ic|(USB)/EFI/BOOT/BOOTx64.EFI}}. This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.}}<br />
<br />
=== Important UEFI Shell commands ===<br />
<br />
UEFI Shell commands usually support {{ic|-b}} option which makes output pause after each page. Run {{ic|help -b}} to list available internal commands. Available commands are either built into the shell or discrete EFI applications.<br />
<br />
For more info see [https://software.intel.com/en-us/articles/efi-shells-and-scripting/ Intel Scripting Guide 2008] and [https://software.intel.com/en-us/articles/uefi-shell Intel "Course" 2011].<br />
<br />
==== bcfg ====<br />
<br />
{{ic|bcfg}} modifies the UEFI NVRAM entries which allows the user to change the boot entries or driver options. This command is described in detail in page 96 (Section 5.3) of the [https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf UEFI Shell Specification 2.2] document.<br />
<br />
{{Note|<br />
* Try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries on your system.<br />
* UEFI Shell v1 official binary does not support {{ic|bcfg}} command. See [[#Obtaining UEFI Shell]] for a modified UEFI Shell v2 binary which may work in UEFI pre-2.3 firmwares.<br />
}}<br />
<br />
To dump a list of current boot entries:<br />
<br />
Shell> bcfg boot dump -v<br />
<br />
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu:<br />
<br />
Shell> bcfg boot add 3 FS0:\EFI\refind\refind_x64.efi "rEFInd"<br />
<br />
where {{ic|FS0:}} is the mapping corresponding to the EFI system partition and {{ic|FS0:\EFI\refind\refind_x64.efi}} is the file to be launched.<br />
<br />
To add an entry to boot directly into your system without a bootloader, configure a boot option using your kernel as an [[EFISTUB#UEFI_Shell|EFISTUB]]:<br />
<br />
Shell> bcfg boot add '''N''' fs'''V''':\vmlinuz-linux "Arch Linux"<br />
Shell> bcfg boot -opt '''N''' "root='''/dev/sdX#''' initrd=\initramfs-linux.img"<br />
<br />
where {{ic|N}} is the priority, {{ic|V}} is the volume number of your EFI system partition, and {{ic|/dev/sdX#}} is your root partition.<br />
<br />
To remove the 4th boot option:<br />
<br />
Shell> bcfg boot rm 3<br />
<br />
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu):<br />
<br />
Shell> bcfg boot mv 3 0<br />
<br />
For bcfg help text:<br />
<br />
Shell> help bcfg -v -b<br />
<br />
or:<br />
<br />
Shell> bcfg -? -v -b<br />
<br />
==== map ====<br />
<br />
{{ic|map}} displays a list of device mappings i.e. the names of available file systems ({{ic|FS0}}) and storage devices ({{ic|blk0}}).<br />
<br />
Before running file system commands such as {{ic|cd}} or {{ic|ls}}, you need to change the shell to the appropriate file system by typing its name:<br />
<br />
Shell> FS0:<br />
FS0:\> cd EFI/<br />
<br />
==== edit ====<br />
<br />
{{ic|edit}} provides a basic text editor with an interface similar to nano, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
For example, to edit rEFInd's {{ic|refind.conf}} in the EFI system partition ({{ic|FS0:}} in the firmware),<br />
<br />
Shell> edit FS0:\EFI\refind\refind.conf<br />
<br />
Type {{ic|Ctrl-E}} for help.<br />
<br />
== UEFI drivers ==<br />
<br />
{{Expansion|Explain what are and how to use UEFI drivers.}}<br />
<br />
== UEFI bootable media ==<br />
<br />
=== Create UEFI bootable USB from ISO ===<br />
<br />
Follow [[USB flash installation media#BIOS and UEFI bootable USB]].<br />
<br />
=== Remove UEFI boot support from optical media ===<br />
<br />
{{Note|<br />
* This section mentions removing UEFI boot support from a '''CD/DVD only''' (Optical Media booting via EL Torito), not from a USB flash drive.<br />
* In order to hide the UEFI equipment on USB stick, use a partition editor after having copied the ISO to the flash drive. Remove the partition of type {{ic|EF}}. '''Do not''' accept offers to convert to GPT.<br />
}}<br />
<br />
Most of the 32-bit EFI Macs and some 64-bit EFI Macs refuse to boot from a UEFI(X64)+BIOS bootable CD/DVD. If one wishes to proceed with the installation using optical media, it might be necessary to remove UEFI support first.<br />
<br />
* Mount the official installation media and obtain the {{ic|archisolabel}} as shown in the previous section.<br />
<br />
# mount -o loop ''input.iso'' /mnt/iso<br />
<br />
* Then rebuild the ISO, excluding the UEFI optical media booting support, using {{ic|xorriso}} from {{pkg|libisoburn}}. Be sure to set the correct archisolabel, e.g. "ARCH_201411" or similar:<br />
<br />
{{bc|1=<br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "''archisolabel''" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared by $USER" \<br />
-eltorito-boot isolinux/isolinux.bin \<br />
-eltorito-catalog isolinux/boot.cat \<br />
-no-emul-boot -boot-load-size 4 -boot-info-table \<br />
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \<br />
-output ''output.iso'' /mnt/iso/<br />
}}<br />
<br />
* Burn {{ic|''output.iso''}} to optical media and proceed with installation normally.<br />
<br />
=== Booting 64-bit kernel on 32-bit UEFI ===<br />
<br />
Official ISO ([[Archiso]]) does not support booting on 32-bit (IA32) UEFI systems ({{Bug|53182}}) since it uses EFISTUB (via [[systemd-boot]] boot manager for menu) for booting the kernel in UEFI mode. To boot a 64-bit kernel with 32-bit UEFI you have to use a boot loader that does not rely on EFI boot stub for launching kernels.<br />
<br />
{{Tip|[[Archboot]] iso supports booting on 32-bit (IA32) UEFI systems.}}<br />
<br />
==== Using GRUB ====<br />
<br />
This section describes how to setup [[GRUB]] as the USB's UEFI bootloader.<br />
<br />
* [[USB flash installation media#Using_manual_formatting|Create an editable USB Flash Installation]]. Since we are going to use GRUB, you only need to follow the steps up until the {{ic|syslinux}} part<br />
<br />
* [[GRUB/Tips and tricks#GRUB standalone|Create a GRUB standalone image]] for 32-bit UEFI systems:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg<br />
# grub-mkstandalone -d /usr/lib/grub/i386-efi -O i386-efi --modules="part_gpt part_msdos" --locales="en@quot" --themes="" -o "''/mnt/usb/''EFI/boot/bootia32.efi" "boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
* Create {{ic|''/mnt/usb''/EFI/boot/grub.cfg}} with the following contents (replace {{ic|ARCH_YYYYMM}} with the required archiso label e.g. {{ic|ARCH_201507}}):<br />
<br />
{{Tip|<br />
* The archiso label can be aquired from the ''.iso'' file with {{ic|isoinfo}} from {{Pkg|cdrtools}} or {{ic|iso-info}} from {{Pkg|libcdio}}.<br />
* The given configuration entries can also be entered inside a [[GRUB#Using_the_command_shell|GRUB command-shell]].<br />
}}<br />
<br />
For the official ISO:<br />
<br />
{{hc|''/mnt/usb''/EFI/boot/grub.cfg|2=<br />
insmod part_gpt<br />
insmod part_msdos<br />
insmod fat<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
insmod video_bochs<br />
insmod video_cirrus<br />
<br />
insmod font<br />
<br />
if loadfont "${prefix}/fonts/unicode.pf2" ; then<br />
insmod gfxterm<br />
set gfxmode="1024x768x32;auto"<br />
terminal_input console<br />
terminal_output gfxterm<br />
fi<br />
<br />
menuentry "Arch Linux archiso x86_64 UEFI USB" {<br />
set gfxpayload=keep<br />
search --no-floppy --set=root --label ''ARCH_YYYYMM''<br />
linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=''ARCH_YYYYMM'' add_efi_memmap<br />
initrd /arch/boot/intel_ucode.img /arch/boot/x86_64/archiso.img<br />
}<br />
}}<br />
<br />
Durring installation, in the [[Installation guide#Boot loader|boot loader installation step]], [[GRUB#Installation_2|install GRUB]] using the option {{ic|1=--target=i386-efi}}.<br />
<br />
== Testing UEFI in systems without native support ==<br />
<br />
=== OVMF for virtual machines ===<br />
<br />
[https://tianocore.github.io/ovmf/ OVMF] is a TianoCore project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware and a separate non-volatile variable store for QEMU.<br />
<br />
You can install {{pkg|ovmf}} from the extra repository.<br />
<br />
It is [https://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt advised] to make a local copy of the non-volatile variable store for your virtual machine:<br />
<br />
$ cp /usr/share/ovmf/x64/OVMF_VARS.fd my_uefi_vars.bin<br />
<br />
To use the OVMF firmware and this variable store, add following to your QEMU command:<br />
<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd \<br />
-drive if=pflash,format=raw,file=my_uefi_vars.bin<br />
<br />
For example:<br />
<br />
$ qemu-system-x86_64 -enable-kvm -m 1G -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd -drive if=pflash,format=raw,file=my_uefi_vars.bin …<br />
<br />
=== DUET for BIOS only systems ===<br />
<br />
DUET was a TianoCore project that enabled chainloading a full UEFI environment from a BIOS system, in a way similar to BIOS OS booting. This method is being discussed extensively in https://www.insanelymac.com/forum/topic/186440-linux-and-windows-uefi-boot-using-tianocore-duet-firmware/. Pre-build DUET images can be downloaded from one of the repos at https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer. Specific instructions for setting up DUET is available at https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/blob/master/Migle_BootDuet_INSTALL.txt . However, as of November 2018, the DUET code has been removed from TianoCore git repository.<br />
<br />
You can also try https://sourceforge.net/projects/cloverefiboot/ which provides modified DUET images that may contain some system specific fixes and is more frequently updated compared to the gitlab repos.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Windows 7 will not boot in UEFI mode ===<br />
<br />
{{Note|Windows 7 can boot in pure UEFI class 3 without CSM support, though installation requires CSM ([https://support.microsoft.com/en-us/kb/2828074 specifically INT 10 H]).}}<br />
<br />
If you have installed Windows to a different hard disk with GPT partitioning and still have a MBR partitioned hard disk in your computer, then it is possible that the firmware (UEFI) is starting its CSM support (for booting MBR partitions) and therefore Windows will not boot. To solve this merge your MBR hard disk to GPT partitioning or disable the SATA port where the MBR hard disk is plugged in or unplug the SATA connector from this hard disk.<br />
<br />
Mainboards with this kind of problem:<br />
<br />
* Gigabyte Z77X-UD3H rev. 1.1 (UEFI version F19e)<br />
** The firmware option for booting "UEFI Only" does not prevent the firmware from starting CSM.<br />
<br />
=== Windows changes boot order ===<br />
<br />
If you [[dual boot with Windows]] and your motherboard just boots Windows immediately instead of your chosen EFI application, there are several possible causes and workarounds.<br />
<br />
* Ensure [[Dual boot with Windows#Fast_Start-Up|Fast Startup]] is disabled in your Windows power options<br />
* Ensure [[Secure Boot]] is disabled in your BIOS (if you are not using a signed boot loader)<br />
* Ensure your UEFI boot order does not have Windows Boot Manager set first e.g. using [[#efibootmgr]] and what you see in the configuration tool of the UEFI. Some motherboards override by default any settings set with efibootmgr by Windows if it detects it. This is confirmed in a Packard Bell laptop.<br />
* If your motherboard is booting the default boot path ({{ic|\EFI\BOOT\BOOTX64.EFI}}), this file may have been overwritten with the Windows boot loader. Try setting the correct boot path e.g. using [[#efibootmgr]].<br />
* If the previous steps do not work, you can tell the Windows boot loader to run a different EFI application. From a Windows Administrator command prompt: {{bc|# bcdedit /set "{bootmgr}" path "\EFI\''path''\''to''\''app.efi''"}}<br />
* Alternatively, you can set a startup script in Windows that ensures that the boot order is set correctly every time you boot Windows.<br />
*# Open a command prompt with admin privlages. Run {{ic|bcdedit /enum firmware}} and find your desired boot entry.<br />
*# Copy the Identifier, including the brackets, e.g. {{ic|<nowiki>{31d0d5f4-22ad-11e5-b30b-806e6f6e6963}</nowiki>}}<br />
*# Create a batch file with the command {{ic|bcdedit /set "{fwbootmgr}" DEFAULT "{''copied boot identifier''}"}}<br />
*# Open ''gpedit.msc'' and under ''Local Computer Policy > Computer Configuration > Windows Settings > Scripts(Startup/Shutdown)'', choose ''Startup''<br />
*# Under the ''Scripts'' tab, choose the ''Add'' button, and select your batch file<br />
<br />
=== USB media gets struck with black screen ===<br />
<br />
This issue can occur due to [[KMS]] issue. Try [[Kernel mode setting#Disabling_modesetting|Disabling KMS]] while booting the USB.<br />
<br />
=== UEFI boot loader does not show up in firmware menu ===<br />
<br />
On certain UEFI motherboards like some boards with an Intel Z77 chipset, adding entries with {{ic|efibootmgr}} or {{ic|bcfg}} from the UEFI Shell will not work because they do not show up on the boot menu list after being added to NVRAM.<br />
<br />
This issue is caused because the motherboards can only load Microsoft Windows. To solve this you have to place the ''.efi'' file in the location that Windows uses.<br />
<br />
Copy the {{ic|bootx64.efi}} file from the Arch Linux installation medium ({{ic|FSO:}}) to the Microsoft directory your [[ESP]] partition on your hard drive ({{ic|FS1:}}). Do this by booting into EFI shell and typing:<br />
<br />
Shell> mkdir FS1:\EFI\Microsoft<br />
Shell> mkdir FS1:\EFI\Microsoft\Boot<br />
Shell> cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi<br />
<br />
After reboot, any entries added to NVRAM should show up in the boot menu.<br />
<br />
=== System boots to EFI shell after hardware change or starting other operating system ===<br />
<br />
EFI stores state on the motherboard, called EFIVARS. Your bootloader (e.g. GRUB) may need to set up these variables in a certain way in order to boot. If your hardware configuration changes, or you boot into another operating system which overwrites these variables (Windows), you may be dumped into the EFI shell upon attempting to boot Arch Linux since the EFIVARS are incorrect and EFI can no longer find your bootloader.<br />
<br />
If you are not concerned about supporting dual-booting, you can install GRUB to the default EFI boot location. In this setup, EFI will always find your bootloader on this drive since it is in the default location, which doesn't depend on the EFIVARS being correct. Your system should continue to boot even if another OS has changed the EFIVARS, or your hardware configuration has made the EFIVARS no longer correct for your system.<br />
<br />
To do this with {{ic|grub-install}}, use the {{ic|--removable}} flag. For example (update {{ic|/boot/}} to be the path to your EFI partition):<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=/boot/ --bootloader-id=GRUB --removable<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:UEFI]]<br />
* [https://www.uefi.org/home/ UEFI Forum] - contains the official [https://uefi.org/specifications UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
* [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? - A blog post by AdamW]<br />
* [https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txt Linux Kernel x86_64 UEFI Documentation]<br />
* [https://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-homepage-general-technology.html Intel's page on EFI]<br />
* [https://firmware.intel.com/ Intel Architecture Firmware Resource Center]<br />
* [https://firmware.intel.com/blog/linux-efi-boot-stub Matt Fleming - The Linux EFI Boot Stub]<br />
* [https://firmware.intel.com/blog/accessing-uefi-variables-linux Matt Fleming - Accessing UEFI Variables from Linux]<br />
* [https://www.rodsbooks.com/linux-uefi/ Rod Smith - Linux on UEFI: A Quick Installation Guide]<br />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<br />
* [https://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]<br />
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]<br />
* [https://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]<br />
* [https://www.tianocore.org/ Intel's TianoCore Project] for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox<br />
* [https://jdebp.eu/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
* [https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq Microsoft's Windows and GPT FAQ]<br />
* [https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/wikis/Windows_x64_BIOS_to_UEFI Convert Windows x64 from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
* [https://gitlab.com/tianocore_uefi_duet_builds/tianocore_uefi_duet_installer/wikis/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
* [https://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
* [https://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]<br />
* [https://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel Documentation]<br />
* [https://web.archive.org/web/20130929114218/http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Microcode&diff=372697Microcode2015-05-05T18:10:49Z<p>ColdPie: We can assume users are up-to-date; I don't think specific version numbers are useful.</p>
<hr />
<div>[[Category:CPU]]<br />
[[de:Microcode]]<br />
[[es:Microcode]]<br />
[[ja:マイクロコード]]<br />
[[ru:Microcode]]<br />
[[zh-CN:Microcode]]<br />
{{Expansion|Better explain ''why'' microcodes are needed instead of what they are}}<br />
Processor manufacturers release stability and security updates to the processor [[Wikipedia:Microcode|microcode]]. While microcode can be updated through the BIOS, the Linux kernel is also able to apply these updates during boot. These updates provide bug fixes that can be critical to the stability of your system. Without these updates, you may experience spurious crashes or unexpected system halts that can be difficult to track down.<br />
<br />
Users of CPUs belonging to the Intel Haswell and Broadwell processor families in particular must install these microcode updates to ensure system stability. But all Intel users should install the updates as a matter of course.<br />
<br />
== Updating microcode ==<br />
<br />
For AMD processors the microcode updates are available in {{Pkg|linux-firmware}}, which is installed as part of the base system. No further action is needed.<br />
<br />
For Intel processors, install {{Pkg|intel-ucode}} and continue reading.<br />
<br />
=== Enabling Intel microcode updates ===<br />
<br />
Microcode must be loaded by the bootloader. Because of the wide variability in users' early-boot configuration, Intel microcode updates may not be triggered automatically by Arch's default configuration. Many AUR kernels have followed the path of the official Arch kernels in this regard.<br />
<br />
These updates must be enabled by adding {{ic|/boot/intel-ucode.img}} as the first initrd in the bootloader config file. This is in addition to the normal initrd file. See below for instructions for common bootloaders.<br />
<br />
=== Specific examples ===<br />
<br />
==== EFI boot stub / EFI handover ====<br />
<br />
Append two {{ic|1=initrd=}} options:<br />
<br />
{{bc|1=initrd=/intel-ucode.img initrd=/initramfs-linux.img}}<br />
<br />
==== Gummiboot ====<br />
<br />
Use the {{ic|initrd}} option twice in {{ic|/boot/loader/entries/*.conf}}:<br />
<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /intel-ucode.img<br />
initrd /initramfs-linux.img<br />
options ...<br />
<br />
==== rEFInd ====<br />
<br />
Edit boot options in {{ic|/boot/refind_linux.conf}} as per EFI boot stub above, example:<br />
<br />
"Boot with standard options" "ro root=UUID=(...) quiet initrd=intel-ucode.img initrd=initramfs-linux.img"<br />
<br />
Users employing manual stanzas in {{ic|/boot/refind.conf}} to define the kernels should simply add {{ic|1=initrd=/intel-ucode.img}} or {{ic|/boot/intel-ucode.img}} as required to the options line, and not in the main part of the stanza.<br />
<br />
==== Grub ====<br />
<br />
''grub-mkconfig'' will automatically detect the microcode update and configure grub appropriately. After installing the {{Pkg|intel-ucode}} package, users are directed to regenerate the grub config to activate loading the microcode update by running {{ic|# grub-mkconfig -o /boot/grub/grub.cfg}}.<br />
<br />
Alternatively, users that manage their grub config file manually can add {{ic|/intel-ucode.img}} or {{ic|/boot/intel-ucode.img}} to {{ic|grub.cfg}} as follows:<br />
<br />
[...]<br />
echo 'Loading initial ramdisk ...'<br />
initrd /intel-ucode.img /initramfs-linux.img<br />
[...]<br />
<br />
{{Note|Repeat it for each menu entry.}}<br />
<br />
{{Warning|This file will automatically be overwitten by {{ic|/usr/bin/grub-mkconfig}} during certain updates negating the changes. It is strongly recommended to use the configuration directory in {{ic|/etc/grub.d}} to manage your grub configuration needs. }}<br />
<br />
==== Syslinux ====<br />
<br />
{{Note|There must be no spaces between the {{ic|intel-ucode}} and {{ic|initramfs-linux}} initrd files. The period signs also do not signify any shorthand or missing code; the amendment must be made exactly as illustrated below.}}<br />
<br />
Multiple initrd's can be separated by commas in {{ic|/boot/syslinux/syslinux.cfg}}:<br />
<br />
LABEL arch<br />
MENU LABEL Arch Linux<br />
LINUX ../vmlinuz-linux<br />
INITRD ../intel-ucode.img,../initramfs-linux.img<br />
APPEND ...<br />
<br />
== Verifying that microcode got updated on boot ==<br />
<br />
Use {{ic|/usr/bin/dmesg}} to see if the microcode has been updated:<br />
<br />
$ dmesg | grep microcode<br />
<br />
On Intel systems one should see something similar to the following, indicating that microcode is updated early:<br />
<br />
[ 0.000000] CPU0 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.221951] CPU1 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.242064] CPU2 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.262349] CPU3 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.507267] microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507272] microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507276] microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507281] microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507286] microcode: CPU4 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507292] microcode: CPU5 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507296] microcode: CPU6 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507300] microcode: CPU7 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507335] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba<br />
<br />
It is entirely possible, particularly with newer hardware, that there is no microcode update for the CPU. In that case, the output may look like this:<br />
<br />
[ 0.292893] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292899] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292906] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292912] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292956] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba<br />
<br />
On AMD systems microcode is updated a bit later in the boot process, so the output would look something like this:<br />
<br />
[ 0.807879] microcode: CPU0: patch_level=0x01000098<br />
[ 0.807888] microcode: CPU1: patch_level=0x01000098<br />
[ 0.807983] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba<br />
[ 16.150642] microcode: CPU0: new patch_level=0x010000c7<br />
[ 16.150682] microcode: CPU1: new patch_level=0x010000c7<br />
<br />
{{Note|The date displayed does not correspond to the version of the {{Pkg|intel-ucode}} package installed. It does show the last time Intel updated the microcode that corresponds to the specific hardware being updated.}}<br />
<br />
== Which CPUs accept microcode updates ==<br />
<br />
Users may consult either Intel or AMD at the following links to see if a particular model is supported:<br />
<br />
* [http://www.amd64.org/microcode.html AMD's Operating System Research Center].<br />
* [https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24290&lang=eng Intel's download center].<br />
<br />
=== Detecting available microcode update ===<br />
<br />
It is possible to find out if the {{ic|intel-ucode.img}} contains a microcode image for the running CPU with {{AUR|iucode-tool}}.<br />
<br />
* Install {{Pkg|intel-ucode}} (changing initrd is not required for detection)<br />
* Install {{AUR|iucode-tool}} from the [[AUR]]<br />
* {{ic|# modprobe cpuid}}<br />
* {{ic|<nowiki># bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS - </nowiki>}}<br />
:(extract microcode image and search it for your cpuid)<br />
* If an update is available, it should show up below ''selected microcodes''<br />
<br />
== Enabling Intel early microcode loading in custom kernels ==<br />
<br />
In order for early loading to work in custom kernels, "CPU microcode loading support" needs to be compiled into the kernel, NOT compiled as a module. This will enable the "Early load microcode" prompt which should be set to "Y".<br />
<br />
CONFIG_MICROCODE=y<br />
CONFIG_MICROCODE_INTEL=y<br />
CONFIG_MICROCODE_INTEL_EARLY=y<br />
CONFIG_MICROCODE_EARLY=y<br />
<br />
== See also ==<br />
<br />
* [https://flossexperiences.wordpress.com/2013/11/17/updating-microcodes/ Updating microcodes]<br />
* [http://inertiawar.com/microcode/ Notes on Intel Microcode updates]<br />
* [https://www.kernel.org/doc/Documentation/x86/early-microcode.txt Kernel early microcode]<br />
* [http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwelly Erratum found in Haswell/Broadwell]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Microcode&diff=372694Microcode2015-05-05T18:08:46Z<p>ColdPie: Various clarifications and simplifications to instructions.</p>
<hr />
<div>[[Category:CPU]]<br />
[[de:Microcode]]<br />
[[es:Microcode]]<br />
[[ja:マイクロコード]]<br />
[[ru:Microcode]]<br />
[[zh-CN:Microcode]]<br />
{{Expansion|Better explain ''why'' microcodes are needed instead of what they are}}<br />
Processor manufacturers release stability and security updates to the processor [[Wikipedia:Microcode|microcode]]. While microcode can be updated through the BIOS, the Linux kernel is also able to apply these updates during boot. These updates provide bug fixes that can be critical to the stability of your system. Without these updates, you may experience spurious crashes or unexpected system halts that can be difficult to track down.<br />
<br />
Users of CPUs belonging to the Intel Haswell and Broadwell processor families in particular must install these microcode updates to ensure system stability. But all Intel users should install the updates as a matter of course.<br />
<br />
== Updating microcode ==<br />
<br />
For AMD processors the microcode updates are available in {{Pkg|linux-firmware}}, which is installed as part of the base system. No further action is needed.<br />
<br />
For Intel processors, install {{Pkg|intel-ucode}} and continue reading.<br />
<br />
=== Enabling Intel microcode updates ===<br />
<br />
Microcode must be loaded by the bootloader. Because of the wide variability in users' early-boot configuration, Intel microcode updates may not be triggered automatically by Arch's default configuration. Many AUR kernels have followed the path of the official Arch kernels in this regard.<br />
<br />
These updates must be enabled by adding {{ic|/boot/intel-ucode.img}} as the first initrd in the bootloader config file. This is in addition to the normal initrd file. See below for instructions for common bootloaders.<br />
<br />
=== Specific examples ===<br />
<br />
==== EFI boot stub / EFI handover ====<br />
<br />
Append two {{ic|1=initrd=}} options:<br />
<br />
{{bc|1=initrd=/intel-ucode.img initrd=/initramfs-linux.img}}<br />
<br />
==== Gummiboot ====<br />
<br />
Use the {{ic|initrd}} option twice in {{ic|/boot/loader/entries/*.conf}}:<br />
<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /intel-ucode.img<br />
initrd /initramfs-linux.img<br />
options ...<br />
<br />
==== rEFInd ====<br />
<br />
Edit boot options in {{ic|/boot/refind_linux.conf}} as per EFI boot stub above, example:<br />
<br />
"Boot with standard options" "ro root=UUID=(...) quiet initrd=intel-ucode.img initrd=initramfs-linux.img"<br />
<br />
Users employing manual stanzas in {{ic|/boot/refind.conf}} to define the kernels should simply add {{ic|1=initrd=/intel-ucode.img}} or {{ic|/boot/intel-ucode.img}} as required to the options line, and not in the main part of the stanza.<br />
<br />
==== Grub ====<br />
<br />
With the release of grub-1:2.02-beta2-5, ''grub-mkconfig'' will automatically handle the microcode update. After installing the {{Pkg|intel-ucode}} package, Users are directed to regenerate the grub config to activate loading the microcode update by running {{ic|# grub-mkconfig -o /boot/grub/grub.cfg}}.<br />
<br />
Alternatively, users that manage their grub config file manually can add {{ic|/intel-ucode.img}} or {{ic|/boot/intel-ucode.img}} to {{ic|grub.cfg}} as follows:<br />
<br />
[...]<br />
echo 'Loading initial ramdisk ...'<br />
initrd /intel-ucode.img /initramfs-linux.img<br />
[...]<br />
<br />
{{Note|Repeat it for each menu entry.}}<br />
<br />
{{Warning|This file will automatically be overwitten by {{ic|/usr/bin/grub-mkconfig}} during certain updates negating the changes. It is strongly recommended to use the configuration directory in {{ic|/etc/grub.d}} to manage your grub configuration needs. }}<br />
<br />
==== Syslinux ====<br />
<br />
{{Note|There must be no spaces between the {{ic|intel-ucode}} and {{ic|initramfs-linux}} initrd files. The period signs also do not signify any shorthand or missing code; the amendment must be made exactly as illustrated below.}}<br />
<br />
Multiple initrd's can be separated by commas in {{ic|/boot/syslinux/syslinux.cfg}}:<br />
<br />
LABEL arch<br />
MENU LABEL Arch Linux<br />
LINUX ../vmlinuz-linux<br />
INITRD ../intel-ucode.img,../initramfs-linux.img<br />
APPEND ...<br />
<br />
== Verifying that microcode got updated on boot ==<br />
<br />
Use {{ic|/usr/bin/dmesg}} to see if the microcode has been updated:<br />
<br />
$ dmesg | grep microcode<br />
<br />
On Intel systems one should see something similar to the following, indicating that microcode is updated early:<br />
<br />
[ 0.000000] CPU0 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.221951] CPU1 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.242064] CPU2 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.262349] CPU3 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.507267] microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507272] microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507276] microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507281] microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507286] microcode: CPU4 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507292] microcode: CPU5 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507296] microcode: CPU6 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507300] microcode: CPU7 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507335] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba<br />
<br />
It is entirely possible, particularly with newer hardware, that there is no microcode update for the CPU. In that case, the output may look like this:<br />
<br />
[ 0.292893] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292899] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292906] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292912] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292956] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba<br />
<br />
On AMD systems microcode is updated a bit later in the boot process, so the output would look something like this:<br />
<br />
[ 0.807879] microcode: CPU0: patch_level=0x01000098<br />
[ 0.807888] microcode: CPU1: patch_level=0x01000098<br />
[ 0.807983] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba<br />
[ 16.150642] microcode: CPU0: new patch_level=0x010000c7<br />
[ 16.150682] microcode: CPU1: new patch_level=0x010000c7<br />
<br />
{{Note|The date displayed does not correspond to the version of the {{Pkg|intel-ucode}} package installed. It does show the last time Intel updated the microcode that corresponds to the specific hardware being updated.}}<br />
<br />
== Which CPUs accept microcode updates ==<br />
<br />
Users may consult either Intel or AMD at the following links to see if a particular model is supported:<br />
<br />
* [http://www.amd64.org/microcode.html AMD's Operating System Research Center].<br />
* [https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24290&lang=eng Intel's download center].<br />
<br />
=== Detecting available microcode update ===<br />
<br />
It is possible to find out if the {{ic|intel-ucode.img}} contains a microcode image for the running CPU with {{AUR|iucode-tool}}.<br />
<br />
* Install {{Pkg|intel-ucode}} (changing initrd is not required for detection)<br />
* Install {{AUR|iucode-tool}} from the [[AUR]]<br />
* {{ic|# modprobe cpuid}}<br />
* {{ic|<nowiki># bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS - </nowiki>}}<br />
:(extract microcode image and search it for your cpuid)<br />
* If an update is available, it should show up below ''selected microcodes''<br />
<br />
== Enabling Intel early microcode loading in custom kernels ==<br />
<br />
In order for early loading to work in custom kernels, "CPU microcode loading support" needs to be compiled into the kernel, NOT compiled as a module. This will enable the "Early load microcode" prompt which should be set to "Y".<br />
<br />
CONFIG_MICROCODE=y<br />
CONFIG_MICROCODE_INTEL=y<br />
CONFIG_MICROCODE_INTEL_EARLY=y<br />
CONFIG_MICROCODE_EARLY=y<br />
<br />
== See also ==<br />
<br />
* [https://flossexperiences.wordpress.com/2013/11/17/updating-microcodes/ Updating microcodes]<br />
* [http://inertiawar.com/microcode/ Notes on Intel Microcode updates]<br />
* [https://www.kernel.org/doc/Documentation/x86/early-microcode.txt Kernel early microcode]<br />
* [http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwelly Erratum found in Haswell/Broadwell]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Microcode&diff=372688Microcode2015-05-05T17:57:58Z<p>ColdPie: Rewrite introduction to explain why microcode updates are important</p>
<hr />
<div>[[Category:CPU]]<br />
[[de:Microcode]]<br />
[[es:Microcode]]<br />
[[ja:マイクロコード]]<br />
[[ru:Microcode]]<br />
[[zh-CN:Microcode]]<br />
{{Expansion|Better explain ''why'' microcodes are needed instead of what they are}}<br />
Processor manufacturers release stability and security updates to the processor [[Wikipedia:Microcode|microcode]]. While microcode can be updated through the BIOS, the Linux kernel is also able to apply these updates during boot. These updates provide bug fixes that can be critical to the stability of your system. Without these updates, you may experience spurious crashes or unexpected system halts that can be difficult to track down.<br />
<br />
Users of CPUs belonging to the Intel Haswell and Broadwell processor families in particular must install these microcode updates. But all Intel users should install the updates as a matter of course.<br />
<br />
== Updating microcode ==<br />
<br />
For Intel processors, install {{Pkg|intel-ucode}}.<br />
<br />
For AMD processors the microcode updates are available in {{Pkg|linux-firmware}}, which is installed as part of the base system.<br />
<br />
=== Enabling Intel microcode updates ===<br />
<br />
{{Warning|With linux 3.17-2 and linux-lts 3.14.21-2 and newer versions, Intel microcode updates are not triggered automatically any more. Many AUR kernels have followed the path of the official ARCH kernels in this regard: with linux-ck 3.16.6-3, Intel microcode updates are not triggered automatically any more.}}<br />
<br />
These updates must be enabled by adding {{ic|/boot/intel-ucode.img}} as the first initrd in the bootloader config file. This is in addition to the normal initrd file.<br />
<br />
=== Specific examples ===<br />
<br />
==== EFI boot stub / EFI handover ====<br />
<br />
Append two {{ic|1=initrd=}} options:<br />
<br />
{{bc|1=initrd=/intel-ucode.img initrd=/initramfs-linux.img}}<br />
<br />
==== Gummiboot ====<br />
<br />
Use the {{ic|initrd}} option twice in {{ic|/boot/loader/entries/*.conf}}:<br />
<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /intel-ucode.img<br />
initrd /initramfs-linux.img<br />
options ...<br />
<br />
==== rEFInd ====<br />
<br />
Edit boot options in {{ic|/boot/refind_linux.conf}} as per EFI boot stub above, example:<br />
<br />
"Boot with standard options" "ro root=UUID=(...) quiet initrd=intel-ucode.img initrd=initramfs-linux.img"<br />
<br />
Users employing manual stanzas in {{ic|/boot/refind.conf}} to define the kernels should simply add {{ic|1=initrd=/intel-ucode.img}} or {{ic|/boot/intel-ucode.img}} as required to the options line, and not in the main part of the stanza.<br />
<br />
==== Grub ====<br />
<br />
With the release of grub-1:2.02-beta2-5, ''grub-mkconfig'' will automatically handle the microcode update. Users are directed to regenerate the grub config to activate loading the microcode update by running {{ic|# grub-mkconfig -o /boot/grub/grub.cfg}} after installing {{Pkg|intel-ucode}}.<br />
<br />
Alternatively, users wishing to manage their grub config file manually can add {{ic|/intel-ucode.img}} or {{ic|/boot/intel-ucode.img}} to {{ic|grub.cfg}} as follows:<br />
<br />
[...]<br />
echo 'Loading initial ramdisk ...'<br />
initrd /intel-ucode.img /initramfs-linux.img<br />
[...]<br />
<br />
{{Note|Repeat it for each menu entry.}}<br />
<br />
{{Warning|This file will automatically be overwitten by {{ic|/usr/bin/grub-mkconfig}} during certain updates negating the changes.}}<br />
<br />
==== Syslinux ====<br />
<br />
{{Note|There must be no spaces between the {{ic|intel-ucode}} and {{ic|initramfs-linux}} initrd files. The period signs also do not signify any shorthand or missing code; the amendment must be made exactly as illustrated below.}}<br />
<br />
Multiple initrd's can be separated by commas in {{ic|/boot/syslinux/syslinux.cfg}}:<br />
<br />
LABEL arch<br />
MENU LABEL Arch Linux<br />
LINUX ../vmlinuz-linux<br />
INITRD ../intel-ucode.img,../initramfs-linux.img<br />
APPEND ...<br />
<br />
== Verifying that microcode got updated on boot ==<br />
<br />
Use {{ic|/usr/bin/dmesg}} to see if the microcode has been updated:<br />
<br />
$ dmesg | grep microcode<br />
<br />
On Intel systems one should see something similar to the following, indicating that microcode is updated early:<br />
<br />
[ 0.000000] CPU0 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.221951] CPU1 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.242064] CPU2 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.262349] CPU3 microcode updated early to revision 0x1b, date = 2014-05-29<br />
[ 0.507267] microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507272] microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507276] microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507281] microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507286] microcode: CPU4 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507292] microcode: CPU5 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507296] microcode: CPU6 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507300] microcode: CPU7 sig=0x306a9, pf=0x2, revision=0x1b<br />
[ 0.507335] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba<br />
<br />
It is entirely possible, particularly with newer hardware, that there is no microcode update for the CPU. In that case, the output may look like this:<br />
<br />
[ 0.292893] microcode: CPU0 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292899] microcode: CPU1 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292906] microcode: CPU2 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292912] microcode: CPU3 sig=0x306c3, pf=0x2, revision=0x1c<br />
[ 0.292956] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba<br />
<br />
On AMD systems microcode is updated a bit later in the boot process, so the output would look something like this:<br />
<br />
[ 0.807879] microcode: CPU0: patch_level=0x01000098<br />
[ 0.807888] microcode: CPU1: patch_level=0x01000098<br />
[ 0.807983] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba<br />
[ 16.150642] microcode: CPU0: new patch_level=0x010000c7<br />
[ 16.150682] microcode: CPU1: new patch_level=0x010000c7<br />
<br />
{{Note|The date displayed does not correspond to the version of the {{Pkg|intel-ucode}} package installed. It does show the last time Intel updated the microcode that corresponds to the specific hardware being updated.}}<br />
<br />
== Which CPUs accept microcode updates ==<br />
<br />
Users may consult either Intel or AMD at the following links to see if a particular model is supported:<br />
<br />
* [http://www.amd64.org/microcode.html AMD's Operating System Research Center].<br />
* [https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24290&lang=eng Intel's download center].<br />
<br />
=== Detecting available microcode update ===<br />
<br />
It is possible to find out if the {{ic|intel-ucode.img}} contains a microcode image for the running CPU with {{AUR|iucode-tool}}.<br />
<br />
* Install {{Pkg|intel-ucode}} (changing initrd is not required for detection)<br />
* Install {{AUR|iucode-tool}} from the [[AUR]]<br />
* {{ic|# modprobe cpuid}}<br />
* {{ic|<nowiki># bsdtar -Oxf /boot/intel-ucode.img | iucode_tool -tb -lS - </nowiki>}}<br />
:(extract microcode image and search it for your cpuid)<br />
* If an update is available, it should show up below ''selected microcodes''<br />
<br />
== Enabling Intel early microcode loading in custom kernels ==<br />
<br />
In order for early loading to work in custom kernels, "CPU microcode loading support" needs to be compiled into the kernel, NOT compiled as a module. This will enable the "Early load microcode" prompt which should be set to "Y".<br />
<br />
CONFIG_MICROCODE=y<br />
CONFIG_MICROCODE_INTEL=y<br />
CONFIG_MICROCODE_INTEL_EARLY=y<br />
CONFIG_MICROCODE_EARLY=y<br />
<br />
== See also ==<br />
<br />
* [https://flossexperiences.wordpress.com/2013/11/17/updating-microcodes/ Updating microcodes]<br />
* [http://inertiawar.com/microcode/ Notes on Intel Microcode updates]<br />
* [https://www.kernel.org/doc/Documentation/x86/early-microcode.txt Kernel early microcode]<br />
* [http://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwelly Erratum found in Haswell/Broadwell]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&diff=372033Talk:Beginners' guide2015-05-01T19:04:23Z<p>ColdPie: /* Adding a reference to Intel microcode */</p>
<hr />
<div>== Unification ==<br />
=== A single, unified official install guide ===<br />
<br />
{{Note|This is based on talk/consensus in #archlinux. The official [[Installation Guide]] page is going to be expanded (or this guide could be protected, cleaned up and replace it - either works, that could be decided here).}}<br />
<br />
Previously, there has been talk here about merging with the old official install guide, and just having a single official [[Installation Guide]]. However, that didn't happen when the old guide was removed because the [[Beginners' Guide]] was (and is) too long, with too much duplication of other pages after the point where it's necessary (getting the initial network access). In order to be an "official" document, it would also have to be protected - edits by regular users would be proposed on the talk page.<br />
<br />
The installation process now always requires network access, and the ISO ships with both a browser and an IRC client, so it's not necessary to keep so much information on this page, since we have very good coverage elsewhere that surpasses the duplication here. For example, there's no need for the [[Beginners' Guide]] to explain how to do an upgrade as [[Pacman#Upgrading packages]] has much better coverage of the gritty details, and the initial install is already fully upgraded.<br />
<br />
-- [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 21:52, 28 October 2012 (UTC)<br />
<br />
:Yes, the ISO comes with a browser ({{Pkg|elinks}}), but it's not very good with formatting. Some people may prefer to actually print the guide ''(which is a waste of paper, if you ask me, but old timers may feel differently)'', or save it as a PDF/HTML and read it on whatever device they own (smartphone, tablet, etc).<br />
<br />
No need to create a section for this, just reminding that the unification would affect {{Bug|36111}}. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:57, 18 August 2013 (UTC)<br />
<br />
=== Define scope of the guide ===<br />
I'd like to define the scope of the guide(s) better and whether it's OK to remove certain things from the wiki instead of marking them as 'the old way' and maybe moving them to a separate article, if needed. Currently the beginners' guide still has info related to initscripts, like [https://wiki.archlinux.org/index.php/Beginners%27_Guide#Time_zone setting the timezone], but the article on time [https://wiki.archlinux.org/index.php/Time#Time_standard has not]. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 09:56, 30 October 2012 (UTC)<br />
: Right now the Beginner's Guide is "A page where user can get their system installed '''without reading other pages'''". This is where the duplications come from. Maybe we can redefine it. So we can:<br />
: # Improve [[Help:Reading]]. Add some guide about Navigation, Searching, Category and Table of Contents. So users can reach the information they want more easily.<br />
: # Reduce long duplication texts. The two network configuration part is a candicate. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 07:46, 31 October 2012 (UTC)<br />
:The reason for using the manual way of configuring is actually because timedatectl and friends won't work from inside a chroot. We could avoid that by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all) but that would require some minor restructuring, so it's something worth discussing. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 17:28, 3 November 2012 (UTC)<br />
<br />
::''[This comment was pasted here from a different, now deleted discussion]''<br />
:: I think that the goal of the Beginners' Guide is not only to let an Arch novice install the system successfully, but also to introduce him to how an Arch Linux system is structured and the technologies it's based on: we shouldn't think of the Beginners' Guide (or any other article) as a simple howto or step-by-step guide, but as something more formative. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:40, 19 September 2012 (UTC)<br />
<br />
=== Plan ===<br />
If someone was interested and had the time to lay out here a '''detailed''' plan with indications on where to merge every section of the guide and a report of all the problems that could be encountered in the process, it would definitely be the final step before announcing the unification on the forums with full support from the admins, which would mean that at that point only strong and reasonable objections could prevent the unification. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:44, 18 August 2013 (UTC)<br />
<br />
Here is a list of sections that should be merged. Feel free to expand, comment in [[#Comments]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:26, 31 August 2013 (UTC)<br />
<br />
* [[Beginners'_guide#Without_wifi-menu]] -- merge into [[Wireless_network_configuration#Getting_some_useful_information]], leave link to target<br />
* [[Beginners%27_guide#Hardware_clock]] - merge to [[Time]], leave link to target, see [[#Hardware_clock_section]]<br />
* Merge common parts between [[Beginners' guide#Establish an internet connection]] and [[Beginners' guide#Configure_the_network]] into [[Network configuration]] and just link there. <br />
<br />
==== General problems ====<br />
<br />
* ''timedatectl'', ''hostnamectl'', ''localectl'' etc. won't work from inside a chroot, so manual method of configuration is required. This could be avoided by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all). (mentioned in [[#Define scope of the guide]] by [[User:Thestinger]])<br />
<br />
::You might say these are important enough to have users execute by hand (and thus get a better understanding of, hopefully). But as the underlying processes are explained well enough in their respective articles, I'm fine either way. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:34, 20 February 2015 (UTC)<br />
<br />
* Instructions should be clear and concise, taking the [[Installation guide]] as example.<br />
<br />
* [[Beginners'_guide#Troubleshooting_boot_problems]] lacks coherence, and may need expansion. See [[#Blacklisting radeon module]].<br />
<br />
* Add short introduction on differences between BG and other wiki pages. See [[#Installation template]].<br />
<br />
==== Comments ====<br />
<br />
=== Installation template ===<br />
<br />
Another alternative way to unify the two main guides would be to follow the same philosophy we used to write the scenarios in [[Dm-crypt_with_LUKS/Encrypting_an_entire_system]], originally discussed in [[Talk:Dm-crypt#New_idea]]: the new installation guide could be a bare, though ''complete'', list of commands and simple instructions needed to install the system in one example scenario, with links to the various relevant articles for detailed information and adaptations to specific cases. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 21:18, 27 March 2014 (UTC)<br />
<br />
:Well, the Beginners' guide suffers from issues related to both content and style, and I really think they need to be addressed at the same time. Every suggestion so far deals only with one problem.<br />
:'''Content:''' I agree that the purpose of the guide (be it Beginners' or Installation) should be to describe only one scenario and provide links to other articles describing the alternatives. I really like ''this part'' of your suggestion, but it solves only half of the problem.<br />
:'''Style:''' The biggest problem is that Beginners' guide is unique mixture of ''introduction to reading ArchWiki'' and ''introduction to installing and '''using''' Arch Linux'', which are simply inseparable in the context of BG - you just can't expect newcomers to first read [[Help:Reading]] and only then start installing their system. So, there is a little bit of anarchy, as the BG is mostly excused from the [[Help:Style|style guidelines]] and there are no guidelines specifically for the BG. Unifying the two guides would necessarily mean a compromise regarding style, which would not be the best for either beginners or gurus.<br />
:Also, I think that it is a good thing that BG is readable ''without reading other pages'' (as defined in [[#Define scope of the guide]]), because it implies that the most important things have been collected and the readers don't have to click-and-search ''too much''. This is really important for the newcomers, because the orientation in the graph of internal links (I wanted to visualize the graph, but it's just too big) is really difficult - they would need to read dozens of pages (with some [[Help:Style|alien style]] applied) before they had the basic system running. On the other hand, one of the main points of BG should be to prepare the readers for other ArchWiki articles, but sometimes the readers are [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=291207&oldid=285657 too] [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=304473&oldid=295238 spoiled].<br />
:Well, that is my defence of keeping both IG and BG. In my opinion it is enough to just properly define the scope of BG and trim it down to ease the maintenance, addressing the ''content'' part. But of course if there is a suggestion on merging the two guides addressing the ''style'' issues, let's hear it!<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:16, 30 March 2014 (UTC)<br />
<br />
::About the style issue, I don't think experienced users would be so bothered by some pacman, systemctl or nano examples, and the unified guide should probably explicitly warn users that they won't find similar examples in the other articles, which would be a perfect way to invite them to become familiar with [[pacman]], [[systemd]], [[Help:Reading]]... Besides, if the guide will be properly structured, experienced users who don't have their own custom installation notes will be able to just follow the automatic ToC as a memory refresher.<br />
::I disagree that the fact that the "BG is readable ''without reading other pages''" is a good thing, as that's exactly the reason that makes it hard to maintain and encourages duplication of information; if users were used to follow links instead, most of the efforts now spent in improving the BG would be instead spent in properly improving the linked articles, which would then become as easy to follow as the BG is now.<br />
::Anyway, I've proposed a change in [[#Comments]] (under [[#Plan]]) that I think should be more likely to reach general consensus, and that would already be a good step forward.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:35, 31 March 2014 (UTC)<br />
<br />
:::I'm beginning to understand the need for merging. After the BG is slimmed down to cover only one example scenario, the title will be just wrong and the scope will be ''exactly'' the same as for IG. It all depends on whether different target audience and related style differences are enough to justify two guides.<br />
:::I hate being the blocker, so let's slim down BG and when it comes to the point of merging with IG, at least it will not be so shocking. I can't help but to think about it as simple redirecting of BG to IG, which will be (more or less) the eventual outcome, so I will need some time to absorb.<br />
:::Finally, we should also look at [[ArchWiki:Requests#Cleanup: installation category]], so that [[:Category:Getting and installing Arch]] is actually useful for providing alternative scenarios, and to ensure there is a place where to move excessive information from the BG.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 7 April 2014 (UTC)<br />
<br />
::::You are not "the blocker", every opinion is as valuable as the others if well argumented, be it for or against the proposal. Especially in this case where we seem to be the only 2 people interested in discussing...<br />
::::If the unification will eventually be completed, of course the BG will become a redirect to the IG, and the latter will be unprotected (and well watched so it's not turned again into a BG).<br />
::::Let's go on with the change very gradually, that's definitely the best way to let everyone successfully and happily adapt to the new way of following the document, which, if done properly, will be even easier and clearer (no need to compare two guides anymore, just to mention an advantage).<br />
::::Of course [[ArchWiki:Requests#Cleanup: installation category]] is strictly linked to all this, I'll try to get there too.<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:26, 9 April 2014 (UTC)<br />
<br />
:::::I personally would suggest leaving the Installation guide locked after the merger (even if that would lock me out also :). Thing is, if someone went through the effort of researching an addition to the guide, it would be easy for them to bring it up here, in the talk page, and easier for the community to discuss (and implement, if applicable). <br />
:::::Leaving the Installation guide unprotected however would make it open to hasty edits. Even if the IG were well watched as said, a made edit's context may not be sufficiently clear to "judge" it on the spot (confirmed by [[ArchWiki:Reports]]). Having contested content remain (however short) on the main, "official" installation reference is less than ideal.<br />
:::::A compromise may be similar to the [[IRC]] page, which is not protected in the technical sense, but has a warning urging users not to edit the page without prior consensus. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:30, 19 February 2015 (UTC)<br />
<br />
::::::Once upon a time, I absolutely don't even remember where, we even discussed the option of keeping the guide in a protected page, but do all the modifications in a separate open page (as if they were two "master" and "devel" branches), with the admins periodically approving and merging the unstable page into the official one. Thanks to the recently introduced [[Special:MergeHistory]] tool, this job could be easier nowadays. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:06, 20 February 2015 (UTC)<br />
<br />
:::::::That sounds like a good option. Working hypothesis: to make users accustomed to the idea, we could now add a note at the top of the BG, suggesting to first discuss changes on the talk page. After the merger this note would then point to the "development" page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:39, 16 March 2015 (UTC)<br />
<br />
::::::::I think that [[Special:MergeHistory]] is too primitive tool for this, AFAIK its only way of operation is "merge all revisions ''up to'' specified one", i.e. there is no ''cherry-picking'' of feasible revisions. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:50, 16 March 2015 (UTC)<br />
<br />
:::::::::@Alad I'm still thinking about it, I'm not sure whether having 2 protected installation guides would be too confusing. The branch method would certainly be well suited if we really ended up merging the guides into one.<br />
:::::::::@Lahwaacz The way it would work would be (''master'' is protected, contains the whole revisions history and ''will not receive direct edits'' by anyone, including admins):<br />
:::::::::# ''develop'' is initialized with a simple copy of the latest revision of ''master''<br />
:::::::::# Some users make some edits to ''develop''<br />
:::::::::# The wiki staff amends/undos ''develop'' as necessary with additional edits (like it happens now in the only branch)<br />
:::::::::# Once ''develop'' is considered in a good state, [[Special:MergeHistory]] can be used safely, no need for cherry-picking<br />
:::::::::# Go back to 1 (at this step ''develop'' is a redirect to ''master'')<br />
:::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:09, 17 March 2015 (UTC)<br />
<br />
:::::::::A simpler alternative with the same effect would be maintaining a link that points to the latest officially approved revision in the history of the article, for example in a Note in the intro. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:13, 17 March 2015 (UTC)<br />
<br />
::::::::::Take your time, it will take a lot more work to get the BG anywhere near ready for merging. A link with note sounds viable as well; we could add a table with different options below. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:08, 17 March 2015 (UTC)<br />
<br />
== Blacklisting radeon module ==<br />
<br />
Installed Arch on my laptop, during pacstrap the screen went blank, pressing SPACE, CTL+C ... didn't helped only modprobe.blacklist=radeon enabled me to go through the whole installation process.<br />
My graphic card is ATI M96 aka Mobility Radeon HD 4650.<br />
I believe this info and similar problems should be added to the beginner's guide on a Installation's Issues Troubleshooting section. I believe this is important enough to dual post and separate it from the Removing "Kernel modules" talk. p.s. I may add that this is my first desktop Linux experience--[[User:Dhead|Dhead]] ([[User talk:Dhead|talk]]) 06:20, 4 March 2013 (UTC)<br />
<br />
:The beginners' guide should not contain hardware-specific info, if the issue is common enough links can be added to [[Beginners%27_guide#Troubleshooting_boot_problems]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:40, 27 December 2014 (UTC)<br />
<br />
== Newbie here offering thoughts on what could be changed in guide ==<br />
<br />
=== General troubleshooting ===<br />
<br />
Apart from that there should be a section at the very beginning explaining how to troubleshoot your own problems. Learning dmesg -HLkd and journalctl -b etc were helpful tools for me. I also appreciated learning lsblk, lsmod, ls etc from the various articles, but a quick over view of these helpful commands on this page would help newbies like myself. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
: Sorry! Just reading over again, and realizing that I could've saved a tonne of time if I knew the problem of "a bunch of white letters clustered on my screen" was an error I could check. It usually happened when the firmware didn't support something (in my case) but telling the user what he can do when this happens helps ease the wiki hopping. I finally, finally figured out how to debug most of my own problems and I think that is the number one thing this guide should do. No offense, but it would also lessen the load on the "newbie corner" on the forums (not that I know it's loaded or not, but less is better, right?). That way no matter what's written in the guide, if it's incorrect or leads to a bad result, the user can figure out why and what to do.. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:05, 7 June 2013 (UTC)<br />
<br />
:: Another [[Keyboard_Shortcuts|useful article]] that could be mentioned (rebooting from black screens, yay!) [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 00:27, 8 June 2013 (UTC)<br />
<br />
:::Regarding your second point, [[General troubleshooting]] is in Related articles - it could be expanded there. --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:25, 2 July 2014 (UTC)<br />
<br />
=== Mounting partitions and dual-boot ===<br />
<br />
And lastly, the surprisingly tricky bit about "mounting" partitions that do not belong to you on a dual boot system. Ultimately for me what ended up working was knowing which file systems the others could read (esp in a UEFI system). These things can't just be "linked" to because even the pages linked to don't have the information. I got quite a bit of help from friends and google. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
== Gummiboot instructions are out of order. ==<br />
<br />
I'm not certain if this is the same issue as the heading "gummiboot instructions are confusing?", but I encountered this using the Beginner's guide. In "2.4 Mount the partitions", it mentions that you should mount the ESP at /boot. But then in "2.8 Chroot and configure the base system", the root is changed to the new system's mountpoint, and /boot no longer refers to the mounted ESP partition (because this was mounted in the live installation CD, in zsh). When in "2.12.2 For UEFI motherboards" I run the gummiboot install command, it errors saying that it is not a fat32 partition. Furthermore, I'm not sure if I need to actually have the initramfs files that were made during pacstrap in the actual ESP since they were installed to /boot. (My thought is they should be, because the assumption was that the ESP has actually been mounted on /boot since before pacstrap was run.) <br />
<br />
I'm not certain what to do. (I'm new, this is my first time going through this guide.) Could someone please review this? Or perhaps I made a mistake somewhere...?<br />
<br />
[[User:Tmarks|Tmarks]] ([[User talk:Tmarks|talk]]) 14:23, 11 October 2014 (UTC)<br />
<br />
: Hmmm... After that there's a command telling about mounting to {{ic|/mnt/boot}}, so people must mount it correctly to {{ic|/mnt/boot}}. But I think you are right, I's a bit confusing and we should replace preceding {{ic|/boot}} with {{ic|/mnt/boot}} -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 11:00, 15 October 2014 (UTC)<br />
<br />
::I am not sure I follow this completely; the quoted section numbers anyhow. [[Beginners' guide#For UEFI motherboards]] states "It is strongly recommended to have the EFI System Partition mounted at /boot as this is required to automatically update Gummiboot." and then "(replace) $esp with the location of your EFI System Partiton, usually /boot" right before the gummiboot install. Maybe it was updated meanwhile, do we need to adjust something? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:54, 2 January 2015 (UTC)<br />
<br />
== Hardware clock section ==<br />
<br />
The '''Hardware clock''' section instructs users to set their hardware clock to UTC time:<br />
<br />
# hwclock --systohc --utc<br />
<br />
without explaining that this will actually reset the BIOS clock setting. Users are then warned that ''Using localtime on Arch systems may lead to several known and unfixable bugs''.<br />
<br />
Question: what might those unfixable bugs be? I've been following these instructions fairly rigorously on every Arch system I've installed, but just got burned by the clock setting, as I think I spaced out and reset the BIOS clock to localtime, so outgoing mail on the system was thrown off by several hours for a couple of days until one of the users alerted me to the problem. Setting the system clock to UTC is kind of confusing, particularly for beginners. What are the unfixable bugs from doing this? If these don't actually exist I would suggest just setting the hardware clock to localtime. This allows you to check the accuracy of the RTC when snooping around in the BIOS.<br />
<br />
# hwclock --systohc --localtime<br />
<br />
And if there really are unfixable bugs, users should be told that the hardware clock is going to be set to an unfamiliar value, so they don't freak out when they go in the system setup and find that the clock is off by several hours from the time they thought it should be. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 22:33, 5 February 2015 (UTC)<br />
<br />
:[https://lists.archlinux.org//listinfo/arch-general/ arch-general] is a probably a better place to discuss this. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:47, 6 February 2015 (UTC)<br />
<br />
::OK, I added a note explaining that this command would reset the RTC clock, which is probably good enough for the Beginner's Guide. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 08:44, 6 February 2015 (UTC)<br />
<br />
:::I've just finished [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=359876&oldid=359646 expanding] that section, I hope it clarifies some of the doubts. Regarding the unspecified "several known and unfixable bugs" I second the suggestion to ask in the mailing list. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:22, 7 February 2015 (UTC)<br />
<br />
::::Thanks for making those edits -- it's much clearer now. I also like your simplification of my comment. Based on my own experience, it's important to point this out explicitly (that the BIOS clock setting will look funny) even if it is implicitly obvious, if you think about it. "Don't make me think" is not just a rule that applies to websites. <:) -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 09:52, 7 February 2015 (UTC)<br />
<br />
:::::I think the description is good, but a bit verbose for the BG (particularly as this is about booting multiple operations systems, namely Windows). [http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html ut-rc] (linked from [[Time#Time_standard]]) provides some more background, also on the "unfixable bugs".<br />
:::::I'd suggest to merge the more elaborate description to [[Time]], provide a short paragraph on Windows and localtime (and unexpected BIOS clock), and link to the above website. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:34, 22 February 2015 (UTC)<br />
<br />
::::::If you manage to merge the section into [[Time]] I think it's a good thing; I also think the external link can be kept only there: if we want to make the section brief, I'd say that what the readers need to know from the BG is only that they have to make sure the hw clock is set to UTC time and that all the other installed OSs must be set accordingly (Arch will consider the hw clock to be set to UTC by default). Then, if they want to know why, or if they want to use localtime for some reason, they can be sent to read [[Time]] to understand all the pros and the cons. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:15, 23 February 2015 (UTC)<br />
<br />
== Static IP ==<br />
<br />
I'd like to discuss whether to keep [[#Beginners' guide#Static IP]] or not. [[dhcpcd#Fallback static profile]] could easily be expanded to cover this, and most (home) routers provide DHCP by default. Having the information in [[dhcpcd]] also benefits [[Beginners' guide#Wired]] which directly links to that article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:20, 28 March 2015 (UTC)<br />
<br />
:I assume you'd replace it with a link to [[dhcpcd#Fallback static profile]], +1 from me. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:19, 29 March 2015 (UTC)<br />
<br />
:I'm -1 on this idea. Fallback is useful for headless installs, yes, but that's not a BG topic.? If a user starts configuring [[Beginners' guide#Static IP]], this means default ISO booting DHCP has failed. Making a static connection fallback only delays startup further in this case.. because DHCP will fail again first. <br />
:Sidenote: What one might consider, is open a flyspray suggesting the ISO default dhcpcd config could gain a fallback static IP config (with both 192.168.* and 10.10.* IPs/routes it would probably be reachable for the majority of routers). <s>Doing such might be considered network intrusive by some users though.</s> edit: since it would be a passive config, not really intrusive. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:57, 29 March 2015 (UTC)<br />
<br />
::Well, the idea is to change/expand the dhcpcd section first to include fallback as a sub-section. The main content would be a regular static profile, with info merged from the BG, and named [[dhcpcd#Static profile]]. I like suggesting a default config though. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:16, 29 March 2015 (UTC)<br />
<br />
:::Please drop a quick note, if you open a bug for it (I do the same). Sub-section or not, this part makes no sense for BG readers of that section imo. Moving the current dhcpcd content of the section, ok - but that's a neat seven lines including code and not really worth it. Moving the whole section comes at the expense of having it verbose incl. interface identification in [[dhcpcd]]. I'm neutral on that. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:45, 29 March 2015 (UTC)<br />
<br />
::::I also doubted if it was worth the effort, hence my asking. Still, I'd like some relation to the chroot section, if only a Tip for users to save/copy their config for later use. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:21, 1 April 2015 (UTC)<br />
<br />
:::::Good idea, added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=368819&oldid=368817]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:41, 6 April 2015 (UTC)<br />
<br />
== Linked to 'parted' Manual doesn't list ext3 or ext4 for fs-type ==<br />
<br />
Hi guys. Recent Arch convert here. Loving it. No bloat! Noticed this during Beginners Guid install though:<br />
<br />
In the section on using parted ( [[Beginners%27_guide#Partition_schemes]] ), it links to the Gnu parted manual at [http://www.gnu.org/software/parted/manual/parted.html#mkpart http://www.gnu.org/software/parted/manual/parted.html#mkpart] for fs-types, but the (rather dated?) manual doesn't list ext3 or ext4. At this point I 'guessed' ext2 was the right choice... Only to find that LATER in the 'Beginners Guide' page it recommended ext4. Damn! Wasn't sure if I had to go back and re-do. Seemed not. But anyway, confusing for 'Beginners'. Anyway, dare not edit the wiki being an Arch noob at this point. Keep up the good work! Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 00:53, 7 April 2015 (UTC)<br />
<br />
:Yes, this is a rather confusing concept: the file system type associated to a partition is a different thing from the file system that you later use to format that partition... It's explained in a bit clearer way in [[Wikipedia:Disk_partitioning#PC_partition_types]], but we should probably explain it better here too.<br />
:In theory, using "ext2", "ext3" or "ext4" when you use {{ic|(parted) mkpart}} shouldn't make any difference at all, as they all set the same partition type code. What does make a difference is the file system you choose when you actually format the partition in [[Beginners'_guide#Create_filesystems]].<br />
:Of course it's wise to make sure the ''fs-type'' corresponds to the file system that is going to be used, but even though I've never tested it, I guess you could use e.g. "NTFS" for ''fs-type'' and still be able to format the partition with ext4 or whatever file system you want.<br />
:— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:49, 7 April 2015 (UTC)<br />
<br />
:: Oh, so for ext3/4 one should just set fs-type to ext2 in parted (etc). Lesson learnt. A one liner would be good saying something like "If you don't know any better, set fs-type to ext2 (Which is the correct option for ext2/3/4), and then format with ext4 below." -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 23:32, 7 April 2015 (UTC)<br />
<br />
:::We needed something more generic and educational, I've added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&action=historysubmit&diff=368977&oldid=368819], I hope it's clear enough, please re-open the discussion if it's not :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:17, 8 April 2015 (UTC)<br />
<br />
::::Looks great. Loving the Arch way, community, Wiki etc. Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 08:49, 8 April 2015 (UTC)<br />
<br />
::::Actually, parted 3.2 has an explicit label for ext4: {{bc|<nowiki><br />
(parted) help mkpart <br />
mkpart PART-TYPE [FS-TYPE] START END make a partition<br />
...<br />
FS-TYPE is one of: btrfs, nilfs2, </nowiki>'''ext4, ext3'''<nowiki>, ext2, fat32, fat16, hfsx, hfs+, hfs, jfs, swsusp, linux-swap(v1), linux-swap(v0),<br />
ntfs, reiserfs, hp-ufs, sun-ufs, xfs, apfs2, apfs1, asfs, amufs5, amufs4, amufs3, amufs2, amufs1, amufs0, amufs, affs7, affs6,<br />
affs5, affs4, affs3, affs2, affs1, affs0, linux-swap, linux-swap(new), linux-swap(old)<br />
...<br />
</nowiki>}}<br />
::::If they are all mapped to the same partition code is another matter, so I'm fine with the current wording. Alternatively we could leave out FS-TYPE completely, after all it is optional (but this is not reflected in the BG).<br />
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:41, 8 April 2015 (UTC)<br />
<br />
:::::Do we want to reopen and investigate this further? Thanks for reminding of the help command, however I can find many sources that seem to confirm that many Linux native file systems (but not all of the above!) map to 0x83: [http://www.win.tue.nl/~aeb/partitions/partition_types-1.html] [http://askubuntu.com/questions/230930/whats-the-difference-of-partition-type-and-filesystem-type] [http://www.tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x190.html] [http://thestarman.pcministry.com/asm/mbr/PartTypes.htm] [http://datarecovery.com/rd/hexadecimal-flags-for-partition-type/]. Unfortunately, as [[Wikipedia:Partition_type#Overview]] says, these codes are not standardized, so we won't be able to find an official reference. Last thing, quoting the [http://www.gnu.org/software/parted/manual/parted.html#mkpart manual], " fs-type is required for data partitions (i.e., non-extended partitions)", so I wouldn't leave it out as optional. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:46, 9 April 2015 (UTC)<br />
<br />
::::::The clearest would either be {{ic|mkpart primary linux}} or {{ic|mkpartfs ext4}} but I doubt either is supported... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:47, 9 April 2015 (UTC)<br />
<br />
:::::::I doubt too, I've [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=369201&oldid=368977 replaced] the link to the manual with "help mkpart". — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:21, 10 April 2015 (UTC)<br />
<br />
== "Internet" a proper name? ==<br />
<br />
Re [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&curid=14839&diff=370951&oldid=370932], there's an article on this: [[Wikipedia:Capitalization of "Internet"]]. It makes no clear case for either generic or proper name, so I'd also stick to the existing lower-case spelling. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 24 April 2015 (UTC)<br />
<br />
:I too tend to prefer the lower-case version for the same reasons as why we spell "telephone" and not "Telephone" etc., but I'm just noting that Wikipedia itself seems to use the upper-case version quite consistently throughout the articles. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:03, 25 April 2015 (UTC)<br />
<br />
== <s>Adding a reference to Intel microcode</s> ==<br />
<br />
[https://wiki.archlinux.org/index.php?title=Beginners%27_guide&action=historysubmit&diff=371418&oldid=371214 I added a short paragraph about CPU microcode], since installing intel-ucode is required on many modern Intel CPUs. The change was reverted, so I'm here discussing it to see what compromise we can make.<br />
<br />
Without installing the package, users will get hard-to-diagnose crashes, often in pthreads. I even got a system lockup. There's currently no obvious reference to the Microcode wiki page in anything a user installing a new system is likely to read. There is a very minor reference to it on the Bootloader page. I don't consider "Related Pages" to imply "Critical reading," and I don't know that a user installing a bootloader would bother with a related page that they don't know that they need (I sure didn't). There's another reference on the BIOS Update page, where again a user wouldn't be there if they didn't know they need to be there. Finally, the Korean language Beginners Guide includes a link to the Microcode. Then there's a bunch of references from computer model-specific pages, as you'd expect, as intel-ucode is required by lots of hardware.<br />
<br />
Worse than all this, I've been using Arch for almost a decade, and I still got bit by this issue this week! For such an important issue, I think we should be much noisier to ensure users install the package to avoid these random crashes. I'm not exaggerating when I say this package is critical. Your system will fail in bizarre and difficult-to-Google ways without it. Most recent Intel CPU users *must* install this package.<br />
<br />
I added this paragraph to the beginners guide, as it includes verbose, step-by-step instructions for how to install a new Arch system. The microcode is loaded by the bootloader, so I added the note there. Apparently Alad that's an inappropriate location, although no rationale was given in the revert message.<br />
<br />
I also added it to the Bootloader page, since I don't think "Related pages" is highlighted enough for how critical this issue is. It was also reverted there. But we can take this discussion to that page.<br />
<br />
So, what can we do to ensure users install this package and avoid random crashes? [[User:ColdPie|ColdPie]] ([[User talk:ColdPie|talk]]) 14:04, 29 April 2015 (UTC)<br />
<br />
: ''I added this paragraph to the beginners guide, as it includes verbose, step-by-step instructions for how to install a new Arch system. The microcode is loaded by the bootloader, so I added the note there.''<br />
: In general, I would say that adding identical sets of information to two different pages is a bad idea. Both have to be maintained and inevitably one is going to fall behind. Also, it is wiki policy to not duplicate information, it should be linked to instead.<br />
: In fact, this issue was a [https://www.archlinux.org/news/changes-to-intel-microcodeupdates/ news item] but that would indeed be hard to spot for new users. I don't have any personal experiences regarding this issue (probably because I took the recommended action as soon as I saw the news item) but if the issue is as serious as you say then new users should be alerted. But I think such an alert should just be a link to the relevant information, not a full summary of it. Adding something like the following to [[Beginners%27_guide#Install_and_configure_a_bootloader]] would seem reasonable to me:<br />
: {{Note|If you have an Intel CPU, you should ensure that your bootloader is configured to handle microcode updates, see [[Microcode]]. Failure to handle microcode updates may result in unexpected crashes.}}<br />
:-- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 15:21, 29 April 2015 (UTC)<br />
<br />
::Yes, I've reverted it for the reasons Chazza outlined as well as [https://wiki.archlinux.org/index.php?title=ArchWiki:Reports&diff=371422&oldid=371352 this report]. I'm however against adding a separate note:<br />
::# A mention on microcode was already added to [[General recommendations#Microcode]], and the BG strongly recommends following this article.<br />
::# From what I've seen in BBS, this issue is specific to Intel Haswell/Broadwell CPUs in combination with nvidia proprietary drivers. I don't think we should describe such corner cases in the BG. The issue also appeared out of the blue, as mentioned, and may lose importance for future hardware or software.<br />
::# The installation guide doesn't mention it, relying on [[General recommendations]] as the current revision of the BG does.<br />
::# Translated guides are expected to exactly follow the English version, apart from details such as default locale. Deviations don't warrant changes to the original guide.<br />
::That said I don't mind adding a small note to [[Bootloaders]] mentioning the news article Chazza linked. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:41, 29 April 2015 (UTC)<br />
:::Added a note to [[Boot loaders]] [https://wiki.archlinux.org/index.php?title=Boot_loaders&curid=14808&diff=371799&oldid=371428]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:05, 29 April 2015 (UTC)<br />
::::Closing, feel free to re-open if there's other arguments. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:47, 1 May 2015 (UTC)<br />
:::::I won't make any changes myself, but for your consideration, there have been four threads about this issue on the forums in the past week about this, some with multiple users: [https://bbs.archlinux.org/viewtopic.php?id=196511 1] [https://bbs.archlinux.org/viewtopic.php?pid=1523284#p1523284 2] [https://bbs.archlinux.org/viewtopic.php?id=196608 3] [https://bbs.archlinux.org/viewtopic.php?id=196676 4]. I found those just by skimming Scimmia's recent posts; probably there are many more. This is biting real users, every day. Maybe it should be somehow improved in the packaging, but in the meantime, I see no reason not to be noisy about it in our user guides. Your call. [[User:ColdPie|ColdPie]] ([[User talk:ColdPie|talk]]) 19:01, 1 May 2015 (UTC)</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&diff=372032Talk:Beginners' guide2015-05-01T19:01:53Z<p>ColdPie: /* Adding a reference to Intel microcode */ Point out some end-user confusion.</p>
<hr />
<div>== Unification ==<br />
=== A single, unified official install guide ===<br />
<br />
{{Note|This is based on talk/consensus in #archlinux. The official [[Installation Guide]] page is going to be expanded (or this guide could be protected, cleaned up and replace it - either works, that could be decided here).}}<br />
<br />
Previously, there has been talk here about merging with the old official install guide, and just having a single official [[Installation Guide]]. However, that didn't happen when the old guide was removed because the [[Beginners' Guide]] was (and is) too long, with too much duplication of other pages after the point where it's necessary (getting the initial network access). In order to be an "official" document, it would also have to be protected - edits by regular users would be proposed on the talk page.<br />
<br />
The installation process now always requires network access, and the ISO ships with both a browser and an IRC client, so it's not necessary to keep so much information on this page, since we have very good coverage elsewhere that surpasses the duplication here. For example, there's no need for the [[Beginners' Guide]] to explain how to do an upgrade as [[Pacman#Upgrading packages]] has much better coverage of the gritty details, and the initial install is already fully upgraded.<br />
<br />
-- [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 21:52, 28 October 2012 (UTC)<br />
<br />
:Yes, the ISO comes with a browser ({{Pkg|elinks}}), but it's not very good with formatting. Some people may prefer to actually print the guide ''(which is a waste of paper, if you ask me, but old timers may feel differently)'', or save it as a PDF/HTML and read it on whatever device they own (smartphone, tablet, etc).<br />
<br />
No need to create a section for this, just reminding that the unification would affect {{Bug|36111}}. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:57, 18 August 2013 (UTC)<br />
<br />
=== Define scope of the guide ===<br />
I'd like to define the scope of the guide(s) better and whether it's OK to remove certain things from the wiki instead of marking them as 'the old way' and maybe moving them to a separate article, if needed. Currently the beginners' guide still has info related to initscripts, like [https://wiki.archlinux.org/index.php/Beginners%27_Guide#Time_zone setting the timezone], but the article on time [https://wiki.archlinux.org/index.php/Time#Time_standard has not]. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 09:56, 30 October 2012 (UTC)<br />
: Right now the Beginner's Guide is "A page where user can get their system installed '''without reading other pages'''". This is where the duplications come from. Maybe we can redefine it. So we can:<br />
: # Improve [[Help:Reading]]. Add some guide about Navigation, Searching, Category and Table of Contents. So users can reach the information they want more easily.<br />
: # Reduce long duplication texts. The two network configuration part is a candicate. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 07:46, 31 October 2012 (UTC)<br />
:The reason for using the manual way of configuring is actually because timedatectl and friends won't work from inside a chroot. We could avoid that by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all) but that would require some minor restructuring, so it's something worth discussing. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 17:28, 3 November 2012 (UTC)<br />
<br />
::''[This comment was pasted here from a different, now deleted discussion]''<br />
:: I think that the goal of the Beginners' Guide is not only to let an Arch novice install the system successfully, but also to introduce him to how an Arch Linux system is structured and the technologies it's based on: we shouldn't think of the Beginners' Guide (or any other article) as a simple howto or step-by-step guide, but as something more formative. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:40, 19 September 2012 (UTC)<br />
<br />
=== Plan ===<br />
If someone was interested and had the time to lay out here a '''detailed''' plan with indications on where to merge every section of the guide and a report of all the problems that could be encountered in the process, it would definitely be the final step before announcing the unification on the forums with full support from the admins, which would mean that at that point only strong and reasonable objections could prevent the unification. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:44, 18 August 2013 (UTC)<br />
<br />
Here is a list of sections that should be merged. Feel free to expand, comment in [[#Comments]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:26, 31 August 2013 (UTC)<br />
<br />
* [[Beginners'_guide#Without_wifi-menu]] -- merge into [[Wireless_network_configuration#Getting_some_useful_information]], leave link to target<br />
* [[Beginners%27_guide#Hardware_clock]] - merge to [[Time]], leave link to target, see [[#Hardware_clock_section]]<br />
* Merge common parts between [[Beginners' guide#Establish an internet connection]] and [[Beginners' guide#Configure_the_network]] into [[Network configuration]] and just link there. <br />
<br />
==== General problems ====<br />
<br />
* ''timedatectl'', ''hostnamectl'', ''localectl'' etc. won't work from inside a chroot, so manual method of configuration is required. This could be avoided by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all). (mentioned in [[#Define scope of the guide]] by [[User:Thestinger]])<br />
<br />
::You might say these are important enough to have users execute by hand (and thus get a better understanding of, hopefully). But as the underlying processes are explained well enough in their respective articles, I'm fine either way. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:34, 20 February 2015 (UTC)<br />
<br />
* Instructions should be clear and concise, taking the [[Installation guide]] as example.<br />
<br />
* [[Beginners'_guide#Troubleshooting_boot_problems]] lacks coherence, and may need expansion. See [[#Blacklisting radeon module]].<br />
<br />
* Add short introduction on differences between BG and other wiki pages. See [[#Installation template]].<br />
<br />
==== Comments ====<br />
<br />
=== Installation template ===<br />
<br />
Another alternative way to unify the two main guides would be to follow the same philosophy we used to write the scenarios in [[Dm-crypt_with_LUKS/Encrypting_an_entire_system]], originally discussed in [[Talk:Dm-crypt#New_idea]]: the new installation guide could be a bare, though ''complete'', list of commands and simple instructions needed to install the system in one example scenario, with links to the various relevant articles for detailed information and adaptations to specific cases. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 21:18, 27 March 2014 (UTC)<br />
<br />
:Well, the Beginners' guide suffers from issues related to both content and style, and I really think they need to be addressed at the same time. Every suggestion so far deals only with one problem.<br />
:'''Content:''' I agree that the purpose of the guide (be it Beginners' or Installation) should be to describe only one scenario and provide links to other articles describing the alternatives. I really like ''this part'' of your suggestion, but it solves only half of the problem.<br />
:'''Style:''' The biggest problem is that Beginners' guide is unique mixture of ''introduction to reading ArchWiki'' and ''introduction to installing and '''using''' Arch Linux'', which are simply inseparable in the context of BG - you just can't expect newcomers to first read [[Help:Reading]] and only then start installing their system. So, there is a little bit of anarchy, as the BG is mostly excused from the [[Help:Style|style guidelines]] and there are no guidelines specifically for the BG. Unifying the two guides would necessarily mean a compromise regarding style, which would not be the best for either beginners or gurus.<br />
:Also, I think that it is a good thing that BG is readable ''without reading other pages'' (as defined in [[#Define scope of the guide]]), because it implies that the most important things have been collected and the readers don't have to click-and-search ''too much''. This is really important for the newcomers, because the orientation in the graph of internal links (I wanted to visualize the graph, but it's just too big) is really difficult - they would need to read dozens of pages (with some [[Help:Style|alien style]] applied) before they had the basic system running. On the other hand, one of the main points of BG should be to prepare the readers for other ArchWiki articles, but sometimes the readers are [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=291207&oldid=285657 too] [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=304473&oldid=295238 spoiled].<br />
:Well, that is my defence of keeping both IG and BG. In my opinion it is enough to just properly define the scope of BG and trim it down to ease the maintenance, addressing the ''content'' part. But of course if there is a suggestion on merging the two guides addressing the ''style'' issues, let's hear it!<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:16, 30 March 2014 (UTC)<br />
<br />
::About the style issue, I don't think experienced users would be so bothered by some pacman, systemctl or nano examples, and the unified guide should probably explicitly warn users that they won't find similar examples in the other articles, which would be a perfect way to invite them to become familiar with [[pacman]], [[systemd]], [[Help:Reading]]... Besides, if the guide will be properly structured, experienced users who don't have their own custom installation notes will be able to just follow the automatic ToC as a memory refresher.<br />
::I disagree that the fact that the "BG is readable ''without reading other pages''" is a good thing, as that's exactly the reason that makes it hard to maintain and encourages duplication of information; if users were used to follow links instead, most of the efforts now spent in improving the BG would be instead spent in properly improving the linked articles, which would then become as easy to follow as the BG is now.<br />
::Anyway, I've proposed a change in [[#Comments]] (under [[#Plan]]) that I think should be more likely to reach general consensus, and that would already be a good step forward.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:35, 31 March 2014 (UTC)<br />
<br />
:::I'm beginning to understand the need for merging. After the BG is slimmed down to cover only one example scenario, the title will be just wrong and the scope will be ''exactly'' the same as for IG. It all depends on whether different target audience and related style differences are enough to justify two guides.<br />
:::I hate being the blocker, so let's slim down BG and when it comes to the point of merging with IG, at least it will not be so shocking. I can't help but to think about it as simple redirecting of BG to IG, which will be (more or less) the eventual outcome, so I will need some time to absorb.<br />
:::Finally, we should also look at [[ArchWiki:Requests#Cleanup: installation category]], so that [[:Category:Getting and installing Arch]] is actually useful for providing alternative scenarios, and to ensure there is a place where to move excessive information from the BG.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 7 April 2014 (UTC)<br />
<br />
::::You are not "the blocker", every opinion is as valuable as the others if well argumented, be it for or against the proposal. Especially in this case where we seem to be the only 2 people interested in discussing...<br />
::::If the unification will eventually be completed, of course the BG will become a redirect to the IG, and the latter will be unprotected (and well watched so it's not turned again into a BG).<br />
::::Let's go on with the change very gradually, that's definitely the best way to let everyone successfully and happily adapt to the new way of following the document, which, if done properly, will be even easier and clearer (no need to compare two guides anymore, just to mention an advantage).<br />
::::Of course [[ArchWiki:Requests#Cleanup: installation category]] is strictly linked to all this, I'll try to get there too.<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:26, 9 April 2014 (UTC)<br />
<br />
:::::I personally would suggest leaving the Installation guide locked after the merger (even if that would lock me out also :). Thing is, if someone went through the effort of researching an addition to the guide, it would be easy for them to bring it up here, in the talk page, and easier for the community to discuss (and implement, if applicable). <br />
:::::Leaving the Installation guide unprotected however would make it open to hasty edits. Even if the IG were well watched as said, a made edit's context may not be sufficiently clear to "judge" it on the spot (confirmed by [[ArchWiki:Reports]]). Having contested content remain (however short) on the main, "official" installation reference is less than ideal.<br />
:::::A compromise may be similar to the [[IRC]] page, which is not protected in the technical sense, but has a warning urging users not to edit the page without prior consensus. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:30, 19 February 2015 (UTC)<br />
<br />
::::::Once upon a time, I absolutely don't even remember where, we even discussed the option of keeping the guide in a protected page, but do all the modifications in a separate open page (as if they were two "master" and "devel" branches), with the admins periodically approving and merging the unstable page into the official one. Thanks to the recently introduced [[Special:MergeHistory]] tool, this job could be easier nowadays. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:06, 20 February 2015 (UTC)<br />
<br />
:::::::That sounds like a good option. Working hypothesis: to make users accustomed to the idea, we could now add a note at the top of the BG, suggesting to first discuss changes on the talk page. After the merger this note would then point to the "development" page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:39, 16 March 2015 (UTC)<br />
<br />
::::::::I think that [[Special:MergeHistory]] is too primitive tool for this, AFAIK its only way of operation is "merge all revisions ''up to'' specified one", i.e. there is no ''cherry-picking'' of feasible revisions. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:50, 16 March 2015 (UTC)<br />
<br />
:::::::::@Alad I'm still thinking about it, I'm not sure whether having 2 protected installation guides would be too confusing. The branch method would certainly be well suited if we really ended up merging the guides into one.<br />
:::::::::@Lahwaacz The way it would work would be (''master'' is protected, contains the whole revisions history and ''will not receive direct edits'' by anyone, including admins):<br />
:::::::::# ''develop'' is initialized with a simple copy of the latest revision of ''master''<br />
:::::::::# Some users make some edits to ''develop''<br />
:::::::::# The wiki staff amends/undos ''develop'' as necessary with additional edits (like it happens now in the only branch)<br />
:::::::::# Once ''develop'' is considered in a good state, [[Special:MergeHistory]] can be used safely, no need for cherry-picking<br />
:::::::::# Go back to 1 (at this step ''develop'' is a redirect to ''master'')<br />
:::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:09, 17 March 2015 (UTC)<br />
<br />
:::::::::A simpler alternative with the same effect would be maintaining a link that points to the latest officially approved revision in the history of the article, for example in a Note in the intro. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:13, 17 March 2015 (UTC)<br />
<br />
::::::::::Take your time, it will take a lot more work to get the BG anywhere near ready for merging. A link with note sounds viable as well; we could add a table with different options below. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:08, 17 March 2015 (UTC)<br />
<br />
== Blacklisting radeon module ==<br />
<br />
Installed Arch on my laptop, during pacstrap the screen went blank, pressing SPACE, CTL+C ... didn't helped only modprobe.blacklist=radeon enabled me to go through the whole installation process.<br />
My graphic card is ATI M96 aka Mobility Radeon HD 4650.<br />
I believe this info and similar problems should be added to the beginner's guide on a Installation's Issues Troubleshooting section. I believe this is important enough to dual post and separate it from the Removing "Kernel modules" talk. p.s. I may add that this is my first desktop Linux experience--[[User:Dhead|Dhead]] ([[User talk:Dhead|talk]]) 06:20, 4 March 2013 (UTC)<br />
<br />
:The beginners' guide should not contain hardware-specific info, if the issue is common enough links can be added to [[Beginners%27_guide#Troubleshooting_boot_problems]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:40, 27 December 2014 (UTC)<br />
<br />
== Newbie here offering thoughts on what could be changed in guide ==<br />
<br />
=== General troubleshooting ===<br />
<br />
Apart from that there should be a section at the very beginning explaining how to troubleshoot your own problems. Learning dmesg -HLkd and journalctl -b etc were helpful tools for me. I also appreciated learning lsblk, lsmod, ls etc from the various articles, but a quick over view of these helpful commands on this page would help newbies like myself. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
: Sorry! Just reading over again, and realizing that I could've saved a tonne of time if I knew the problem of "a bunch of white letters clustered on my screen" was an error I could check. It usually happened when the firmware didn't support something (in my case) but telling the user what he can do when this happens helps ease the wiki hopping. I finally, finally figured out how to debug most of my own problems and I think that is the number one thing this guide should do. No offense, but it would also lessen the load on the "newbie corner" on the forums (not that I know it's loaded or not, but less is better, right?). That way no matter what's written in the guide, if it's incorrect or leads to a bad result, the user can figure out why and what to do.. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:05, 7 June 2013 (UTC)<br />
<br />
:: Another [[Keyboard_Shortcuts|useful article]] that could be mentioned (rebooting from black screens, yay!) [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 00:27, 8 June 2013 (UTC)<br />
<br />
:::Regarding your second point, [[General troubleshooting]] is in Related articles - it could be expanded there. --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:25, 2 July 2014 (UTC)<br />
<br />
=== Mounting partitions and dual-boot ===<br />
<br />
And lastly, the surprisingly tricky bit about "mounting" partitions that do not belong to you on a dual boot system. Ultimately for me what ended up working was knowing which file systems the others could read (esp in a UEFI system). These things can't just be "linked" to because even the pages linked to don't have the information. I got quite a bit of help from friends and google. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
== Gummiboot instructions are out of order. ==<br />
<br />
I'm not certain if this is the same issue as the heading "gummiboot instructions are confusing?", but I encountered this using the Beginner's guide. In "2.4 Mount the partitions", it mentions that you should mount the ESP at /boot. But then in "2.8 Chroot and configure the base system", the root is changed to the new system's mountpoint, and /boot no longer refers to the mounted ESP partition (because this was mounted in the live installation CD, in zsh). When in "2.12.2 For UEFI motherboards" I run the gummiboot install command, it errors saying that it is not a fat32 partition. Furthermore, I'm not sure if I need to actually have the initramfs files that were made during pacstrap in the actual ESP since they were installed to /boot. (My thought is they should be, because the assumption was that the ESP has actually been mounted on /boot since before pacstrap was run.) <br />
<br />
I'm not certain what to do. (I'm new, this is my first time going through this guide.) Could someone please review this? Or perhaps I made a mistake somewhere...?<br />
<br />
[[User:Tmarks|Tmarks]] ([[User talk:Tmarks|talk]]) 14:23, 11 October 2014 (UTC)<br />
<br />
: Hmmm... After that there's a command telling about mounting to {{ic|/mnt/boot}}, so people must mount it correctly to {{ic|/mnt/boot}}. But I think you are right, I's a bit confusing and we should replace preceding {{ic|/boot}} with {{ic|/mnt/boot}} -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 11:00, 15 October 2014 (UTC)<br />
<br />
::I am not sure I follow this completely; the quoted section numbers anyhow. [[Beginners' guide#For UEFI motherboards]] states "It is strongly recommended to have the EFI System Partition mounted at /boot as this is required to automatically update Gummiboot." and then "(replace) $esp with the location of your EFI System Partiton, usually /boot" right before the gummiboot install. Maybe it was updated meanwhile, do we need to adjust something? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:54, 2 January 2015 (UTC)<br />
<br />
== Hardware clock section ==<br />
<br />
The '''Hardware clock''' section instructs users to set their hardware clock to UTC time:<br />
<br />
# hwclock --systohc --utc<br />
<br />
without explaining that this will actually reset the BIOS clock setting. Users are then warned that ''Using localtime on Arch systems may lead to several known and unfixable bugs''.<br />
<br />
Question: what might those unfixable bugs be? I've been following these instructions fairly rigorously on every Arch system I've installed, but just got burned by the clock setting, as I think I spaced out and reset the BIOS clock to localtime, so outgoing mail on the system was thrown off by several hours for a couple of days until one of the users alerted me to the problem. Setting the system clock to UTC is kind of confusing, particularly for beginners. What are the unfixable bugs from doing this? If these don't actually exist I would suggest just setting the hardware clock to localtime. This allows you to check the accuracy of the RTC when snooping around in the BIOS.<br />
<br />
# hwclock --systohc --localtime<br />
<br />
And if there really are unfixable bugs, users should be told that the hardware clock is going to be set to an unfamiliar value, so they don't freak out when they go in the system setup and find that the clock is off by several hours from the time they thought it should be. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 22:33, 5 February 2015 (UTC)<br />
<br />
:[https://lists.archlinux.org//listinfo/arch-general/ arch-general] is a probably a better place to discuss this. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:47, 6 February 2015 (UTC)<br />
<br />
::OK, I added a note explaining that this command would reset the RTC clock, which is probably good enough for the Beginner's Guide. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 08:44, 6 February 2015 (UTC)<br />
<br />
:::I've just finished [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=359876&oldid=359646 expanding] that section, I hope it clarifies some of the doubts. Regarding the unspecified "several known and unfixable bugs" I second the suggestion to ask in the mailing list. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:22, 7 February 2015 (UTC)<br />
<br />
::::Thanks for making those edits -- it's much clearer now. I also like your simplification of my comment. Based on my own experience, it's important to point this out explicitly (that the BIOS clock setting will look funny) even if it is implicitly obvious, if you think about it. "Don't make me think" is not just a rule that applies to websites. <:) -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 09:52, 7 February 2015 (UTC)<br />
<br />
:::::I think the description is good, but a bit verbose for the BG (particularly as this is about booting multiple operations systems, namely Windows). [http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html ut-rc] (linked from [[Time#Time_standard]]) provides some more background, also on the "unfixable bugs".<br />
:::::I'd suggest to merge the more elaborate description to [[Time]], provide a short paragraph on Windows and localtime (and unexpected BIOS clock), and link to the above website. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:34, 22 February 2015 (UTC)<br />
<br />
::::::If you manage to merge the section into [[Time]] I think it's a good thing; I also think the external link can be kept only there: if we want to make the section brief, I'd say that what the readers need to know from the BG is only that they have to make sure the hw clock is set to UTC time and that all the other installed OSs must be set accordingly (Arch will consider the hw clock to be set to UTC by default). Then, if they want to know why, or if they want to use localtime for some reason, they can be sent to read [[Time]] to understand all the pros and the cons. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:15, 23 February 2015 (UTC)<br />
<br />
== Static IP ==<br />
<br />
I'd like to discuss whether to keep [[#Beginners' guide#Static IP]] or not. [[dhcpcd#Fallback static profile]] could easily be expanded to cover this, and most (home) routers provide DHCP by default. Having the information in [[dhcpcd]] also benefits [[Beginners' guide#Wired]] which directly links to that article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:20, 28 March 2015 (UTC)<br />
<br />
:I assume you'd replace it with a link to [[dhcpcd#Fallback static profile]], +1 from me. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:19, 29 March 2015 (UTC)<br />
<br />
:I'm -1 on this idea. Fallback is useful for headless installs, yes, but that's not a BG topic.? If a user starts configuring [[Beginners' guide#Static IP]], this means default ISO booting DHCP has failed. Making a static connection fallback only delays startup further in this case.. because DHCP will fail again first. <br />
:Sidenote: What one might consider, is open a flyspray suggesting the ISO default dhcpcd config could gain a fallback static IP config (with both 192.168.* and 10.10.* IPs/routes it would probably be reachable for the majority of routers). <s>Doing such might be considered network intrusive by some users though.</s> edit: since it would be a passive config, not really intrusive. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:57, 29 March 2015 (UTC)<br />
<br />
::Well, the idea is to change/expand the dhcpcd section first to include fallback as a sub-section. The main content would be a regular static profile, with info merged from the BG, and named [[dhcpcd#Static profile]]. I like suggesting a default config though. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:16, 29 March 2015 (UTC)<br />
<br />
:::Please drop a quick note, if you open a bug for it (I do the same). Sub-section or not, this part makes no sense for BG readers of that section imo. Moving the current dhcpcd content of the section, ok - but that's a neat seven lines including code and not really worth it. Moving the whole section comes at the expense of having it verbose incl. interface identification in [[dhcpcd]]. I'm neutral on that. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:45, 29 March 2015 (UTC)<br />
<br />
::::I also doubted if it was worth the effort, hence my asking. Still, I'd like some relation to the chroot section, if only a Tip for users to save/copy their config for later use. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:21, 1 April 2015 (UTC)<br />
<br />
:::::Good idea, added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=368819&oldid=368817]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:41, 6 April 2015 (UTC)<br />
<br />
== Linked to 'parted' Manual doesn't list ext3 or ext4 for fs-type ==<br />
<br />
Hi guys. Recent Arch convert here. Loving it. No bloat! Noticed this during Beginners Guid install though:<br />
<br />
In the section on using parted ( [[Beginners%27_guide#Partition_schemes]] ), it links to the Gnu parted manual at [http://www.gnu.org/software/parted/manual/parted.html#mkpart http://www.gnu.org/software/parted/manual/parted.html#mkpart] for fs-types, but the (rather dated?) manual doesn't list ext3 or ext4. At this point I 'guessed' ext2 was the right choice... Only to find that LATER in the 'Beginners Guide' page it recommended ext4. Damn! Wasn't sure if I had to go back and re-do. Seemed not. But anyway, confusing for 'Beginners'. Anyway, dare not edit the wiki being an Arch noob at this point. Keep up the good work! Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 00:53, 7 April 2015 (UTC)<br />
<br />
:Yes, this is a rather confusing concept: the file system type associated to a partition is a different thing from the file system that you later use to format that partition... It's explained in a bit clearer way in [[Wikipedia:Disk_partitioning#PC_partition_types]], but we should probably explain it better here too.<br />
:In theory, using "ext2", "ext3" or "ext4" when you use {{ic|(parted) mkpart}} shouldn't make any difference at all, as they all set the same partition type code. What does make a difference is the file system you choose when you actually format the partition in [[Beginners'_guide#Create_filesystems]].<br />
:Of course it's wise to make sure the ''fs-type'' corresponds to the file system that is going to be used, but even though I've never tested it, I guess you could use e.g. "NTFS" for ''fs-type'' and still be able to format the partition with ext4 or whatever file system you want.<br />
:— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:49, 7 April 2015 (UTC)<br />
<br />
:: Oh, so for ext3/4 one should just set fs-type to ext2 in parted (etc). Lesson learnt. A one liner would be good saying something like "If you don't know any better, set fs-type to ext2 (Which is the correct option for ext2/3/4), and then format with ext4 below." -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 23:32, 7 April 2015 (UTC)<br />
<br />
:::We needed something more generic and educational, I've added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&action=historysubmit&diff=368977&oldid=368819], I hope it's clear enough, please re-open the discussion if it's not :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:17, 8 April 2015 (UTC)<br />
<br />
::::Looks great. Loving the Arch way, community, Wiki etc. Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 08:49, 8 April 2015 (UTC)<br />
<br />
::::Actually, parted 3.2 has an explicit label for ext4: {{bc|<nowiki><br />
(parted) help mkpart <br />
mkpart PART-TYPE [FS-TYPE] START END make a partition<br />
...<br />
FS-TYPE is one of: btrfs, nilfs2, </nowiki>'''ext4, ext3'''<nowiki>, ext2, fat32, fat16, hfsx, hfs+, hfs, jfs, swsusp, linux-swap(v1), linux-swap(v0),<br />
ntfs, reiserfs, hp-ufs, sun-ufs, xfs, apfs2, apfs1, asfs, amufs5, amufs4, amufs3, amufs2, amufs1, amufs0, amufs, affs7, affs6,<br />
affs5, affs4, affs3, affs2, affs1, affs0, linux-swap, linux-swap(new), linux-swap(old)<br />
...<br />
</nowiki>}}<br />
::::If they are all mapped to the same partition code is another matter, so I'm fine with the current wording. Alternatively we could leave out FS-TYPE completely, after all it is optional (but this is not reflected in the BG).<br />
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:41, 8 April 2015 (UTC)<br />
<br />
:::::Do we want to reopen and investigate this further? Thanks for reminding of the help command, however I can find many sources that seem to confirm that many Linux native file systems (but not all of the above!) map to 0x83: [http://www.win.tue.nl/~aeb/partitions/partition_types-1.html] [http://askubuntu.com/questions/230930/whats-the-difference-of-partition-type-and-filesystem-type] [http://www.tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x190.html] [http://thestarman.pcministry.com/asm/mbr/PartTypes.htm] [http://datarecovery.com/rd/hexadecimal-flags-for-partition-type/]. Unfortunately, as [[Wikipedia:Partition_type#Overview]] says, these codes are not standardized, so we won't be able to find an official reference. Last thing, quoting the [http://www.gnu.org/software/parted/manual/parted.html#mkpart manual], " fs-type is required for data partitions (i.e., non-extended partitions)", so I wouldn't leave it out as optional. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:46, 9 April 2015 (UTC)<br />
<br />
::::::The clearest would either be {{ic|mkpart primary linux}} or {{ic|mkpartfs ext4}} but I doubt either is supported... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:47, 9 April 2015 (UTC)<br />
<br />
:::::::I doubt too, I've [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=369201&oldid=368977 replaced] the link to the manual with "help mkpart". — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:21, 10 April 2015 (UTC)<br />
<br />
== "Internet" a proper name? ==<br />
<br />
Re [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&curid=14839&diff=370951&oldid=370932], there's an article on this: [[Wikipedia:Capitalization of "Internet"]]. It makes no clear case for either generic or proper name, so I'd also stick to the existing lower-case spelling. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 24 April 2015 (UTC)<br />
<br />
:I too tend to prefer the lower-case version for the same reasons as why we spell "telephone" and not "Telephone" etc., but I'm just noting that Wikipedia itself seems to use the upper-case version quite consistently throughout the articles. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:03, 25 April 2015 (UTC)<br />
<br />
== <s>Adding a reference to Intel microcode</s> ==<br />
<br />
[https://wiki.archlinux.org/index.php?title=Beginners%27_guide&action=historysubmit&diff=371418&oldid=371214 I added a short paragraph about CPU microcode], since installing intel-ucode is required on many modern Intel CPUs. The change was reverted, so I'm here discussing it to see what compromise we can make.<br />
<br />
Without installing the package, users will get hard-to-diagnose crashes, often in pthreads. I even got a system lockup. There's currently no obvious reference to the Microcode wiki page in anything a user installing a new system is likely to read. There is a very minor reference to it on the Bootloader page. I don't consider "Related Pages" to imply "Critical reading," and I don't know that a user installing a bootloader would bother with a related page that they don't know that they need (I sure didn't). There's another reference on the BIOS Update page, where again a user wouldn't be there if they didn't know they need to be there. Finally, the Korean language Beginners Guide includes a link to the Microcode. Then there's a bunch of references from computer model-specific pages, as you'd expect, as intel-ucode is required by lots of hardware.<br />
<br />
Worse than all this, I've been using Arch for almost a decade, and I still got bit by this issue this week! For such an important issue, I think we should be much noisier to ensure users install the package to avoid these random crashes. I'm not exaggerating when I say this package is critical. Your system will fail in bizarre and difficult-to-Google ways without it. Most recent Intel CPU users *must* install this package.<br />
<br />
I added this paragraph to the beginners guide, as it includes verbose, step-by-step instructions for how to install a new Arch system. The microcode is loaded by the bootloader, so I added the note there. Apparently Alad that's an inappropriate location, although no rationale was given in the revert message.<br />
<br />
I also added it to the Bootloader page, since I don't think "Related pages" is highlighted enough for how critical this issue is. It was also reverted there. But we can take this discussion to that page.<br />
<br />
So, what can we do to ensure users install this package and avoid random crashes? [[User:ColdPie|ColdPie]] ([[User talk:ColdPie|talk]]) 14:04, 29 April 2015 (UTC)<br />
<br />
: ''I added this paragraph to the beginners guide, as it includes verbose, step-by-step instructions for how to install a new Arch system. The microcode is loaded by the bootloader, so I added the note there.''<br />
: In general, I would say that adding identical sets of information to two different pages is a bad idea. Both have to be maintained and inevitably one is going to fall behind. Also, it is wiki policy to not duplicate information, it should be linked to instead.<br />
: In fact, this issue was a [https://www.archlinux.org/news/changes-to-intel-microcodeupdates/ news item] but that would indeed be hard to spot for new users. I don't have any personal experiences regarding this issue (probably because I took the recommended action as soon as I saw the news item) but if the issue is as serious as you say then new users should be alerted. But I think such an alert should just be a link to the relevant information, not a full summary of it. Adding something like the following to [[Beginners%27_guide#Install_and_configure_a_bootloader]] would seem reasonable to me:<br />
: {{Note|If you have an Intel CPU, you should ensure that your bootloader is configured to handle microcode updates, see [[Microcode]]. Failure to handle microcode updates may result in unexpected crashes.}}<br />
:-- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 15:21, 29 April 2015 (UTC)<br />
<br />
::Yes, I've reverted it for the reasons Chazza outlined as well as [https://wiki.archlinux.org/index.php?title=ArchWiki:Reports&diff=371422&oldid=371352 this report]. I'm however against adding a separate note:<br />
::# A mention on microcode was already added to [[General recommendations#Microcode]], and the BG strongly recommends following this article.<br />
::# From what I've seen in BBS, this issue is specific to Intel Haswell/Broadwell CPUs in combination with nvidia proprietary drivers. I don't think we should describe such corner cases in the BG. The issue also appeared out of the blue, as mentioned, and may lose importance for future hardware or software.<br />
::# The installation guide doesn't mention it, relying on [[General recommendations]] as the current revision of the BG does.<br />
::# Translated guides are expected to exactly follow the English version, apart from details such as default locale. Deviations don't warrant changes to the original guide.<br />
::That said I don't mind adding a small note to [[Bootloaders]] mentioning the news article Chazza linked. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:41, 29 April 2015 (UTC)<br />
:::Added a note to [[Boot loaders]] [https://wiki.archlinux.org/index.php?title=Boot_loaders&curid=14808&diff=371799&oldid=371428]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 16:05, 29 April 2015 (UTC)<br />
::::Closing, feel free to re-open if there's other arguments. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:47, 1 May 2015 (UTC)<br />
:::::I won't make any changes myself, but for your consideration, there have been four threads about this issue on the forums in the past week about this, some with multiple users: [https://bbs.archlinux.org/viewtopic.php?id=196511 1] [https://bbs.archlinux.org/viewtopic.php?pid=1523284#p1523284 2] [https://bbs.archlinux.org/viewtopic.php?id=196608 3] [https://bbs.archlinux.org/viewtopic.php?id=196676 4]. This is biting real users, every day. Maybe it should be somehow improved in the packaging, but in the meantime, I see no reason not to be noisy about it in our user guides. Your call. [[User:ColdPie|ColdPie]] ([[User talk:ColdPie|talk]]) 19:01, 1 May 2015 (UTC)</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&diff=371781Talk:Beginners' guide2015-04-29T14:04:33Z<p>ColdPie: /* Adding a reference to Intel microcode */ new section</p>
<hr />
<div>== Unification ==<br />
=== A single, unified official install guide ===<br />
<br />
{{Note|This is based on talk/consensus in #archlinux. The official [[Installation Guide]] page is going to be expanded (or this guide could be protected, cleaned up and replace it - either works, that could be decided here).}}<br />
<br />
Previously, there has been talk here about merging with the old official install guide, and just having a single official [[Installation Guide]]. However, that didn't happen when the old guide was removed because the [[Beginners' Guide]] was (and is) too long, with too much duplication of other pages after the point where it's necessary (getting the initial network access). In order to be an "official" document, it would also have to be protected - edits by regular users would be proposed on the talk page.<br />
<br />
The installation process now always requires network access, and the ISO ships with both a browser and an IRC client, so it's not necessary to keep so much information on this page, since we have very good coverage elsewhere that surpasses the duplication here. For example, there's no need for the [[Beginners' Guide]] to explain how to do an upgrade as [[Pacman#Upgrading packages]] has much better coverage of the gritty details, and the initial install is already fully upgraded.<br />
<br />
-- [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 21:52, 28 October 2012 (UTC)<br />
<br />
:Yes, the ISO comes with a browser ({{Pkg|elinks}}), but it's not very good with formatting. Some people may prefer to actually print the guide ''(which is a waste of paper, if you ask me, but old timers may feel differently)'', or save it as a PDF/HTML and read it on whatever device they own (smartphone, tablet, etc).<br />
<br />
No need to create a section for this, just reminding that the unification would affect {{Bug|36111}}. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:57, 18 August 2013 (UTC)<br />
<br />
=== Define scope of the guide ===<br />
I'd like to define the scope of the guide(s) better and whether it's OK to remove certain things from the wiki instead of marking them as 'the old way' and maybe moving them to a separate article, if needed. Currently the beginners' guide still has info related to initscripts, like [https://wiki.archlinux.org/index.php/Beginners%27_Guide#Time_zone setting the timezone], but the article on time [https://wiki.archlinux.org/index.php/Time#Time_standard has not]. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 09:56, 30 October 2012 (UTC)<br />
: Right now the Beginner's Guide is "A page where user can get their system installed '''without reading other pages'''". This is where the duplications come from. Maybe we can redefine it. So we can:<br />
: # Improve [[Help:Reading]]. Add some guide about Navigation, Searching, Category and Table of Contents. So users can reach the information they want more easily.<br />
: # Reduce long duplication texts. The two network configuration part is a candicate. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 07:46, 31 October 2012 (UTC)<br />
:The reason for using the manual way of configuring is actually because timedatectl and friends won't work from inside a chroot. We could avoid that by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all) but that would require some minor restructuring, so it's something worth discussing. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 17:28, 3 November 2012 (UTC)<br />
<br />
::''[This comment was pasted here from a different, now deleted discussion]''<br />
:: I think that the goal of the Beginners' Guide is not only to let an Arch novice install the system successfully, but also to introduce him to how an Arch Linux system is structured and the technologies it's based on: we shouldn't think of the Beginners' Guide (or any other article) as a simple howto or step-by-step guide, but as something more formative. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:40, 19 September 2012 (UTC)<br />
<br />
=== Plan ===<br />
If someone was interested and had the time to lay out here a '''detailed''' plan with indications on where to merge every section of the guide and a report of all the problems that could be encountered in the process, it would definitely be the final step before announcing the unification on the forums with full support from the admins, which would mean that at that point only strong and reasonable objections could prevent the unification. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:44, 18 August 2013 (UTC)<br />
<br />
Here is a list of sections that should be merged. Feel free to expand, comment in [[#Comments]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:26, 31 August 2013 (UTC)<br />
<br />
* [[Beginners'_guide#Without_wifi-menu]] -- merge into [[Wireless_network_configuration#Getting_some_useful_information]], leave link to target<br />
* [[Beginners%27_guide#Hardware_clock]] - merge to [[Time]], leave link to target, see [[#Hardware_clock_section]]<br />
* Merge common parts between [[Beginners' guide#Establish an internet connection]] and [[Beginners' guide#Configure_the_network]] into [[Network configuration]] and just link there. <br />
<br />
==== General problems ====<br />
<br />
* ''timedatectl'', ''hostnamectl'', ''localectl'' etc. won't work from inside a chroot, so manual method of configuration is required. This could be avoided by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all). (mentioned in [[#Define scope of the guide]] by [[User:Thestinger]])<br />
<br />
::You might say these are important enough to have users execute by hand (and thus get a better understanding of, hopefully). But as the underlying processes are explained well enough in their respective articles, I'm fine either way. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:34, 20 February 2015 (UTC)<br />
<br />
* Instructions should be clear and concise, taking the [[Installation guide]] as example.<br />
<br />
* [[Beginners'_guide#Troubleshooting_boot_problems]] lacks coherence, and may need expansion. See [[#Blacklisting radeon module]].<br />
<br />
* Add short introduction on differences between BG and other wiki pages. See [[#Installation template]].<br />
<br />
==== Comments ====<br />
<br />
=== Installation template ===<br />
<br />
Another alternative way to unify the two main guides would be to follow the same philosophy we used to write the scenarios in [[Dm-crypt_with_LUKS/Encrypting_an_entire_system]], originally discussed in [[Talk:Dm-crypt#New_idea]]: the new installation guide could be a bare, though ''complete'', list of commands and simple instructions needed to install the system in one example scenario, with links to the various relevant articles for detailed information and adaptations to specific cases. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 21:18, 27 March 2014 (UTC)<br />
<br />
:Well, the Beginners' guide suffers from issues related to both content and style, and I really think they need to be addressed at the same time. Every suggestion so far deals only with one problem.<br />
:'''Content:''' I agree that the purpose of the guide (be it Beginners' or Installation) should be to describe only one scenario and provide links to other articles describing the alternatives. I really like ''this part'' of your suggestion, but it solves only half of the problem.<br />
:'''Style:''' The biggest problem is that Beginners' guide is unique mixture of ''introduction to reading ArchWiki'' and ''introduction to installing and '''using''' Arch Linux'', which are simply inseparable in the context of BG - you just can't expect newcomers to first read [[Help:Reading]] and only then start installing their system. So, there is a little bit of anarchy, as the BG is mostly excused from the [[Help:Style|style guidelines]] and there are no guidelines specifically for the BG. Unifying the two guides would necessarily mean a compromise regarding style, which would not be the best for either beginners or gurus.<br />
:Also, I think that it is a good thing that BG is readable ''without reading other pages'' (as defined in [[#Define scope of the guide]]), because it implies that the most important things have been collected and the readers don't have to click-and-search ''too much''. This is really important for the newcomers, because the orientation in the graph of internal links (I wanted to visualize the graph, but it's just too big) is really difficult - they would need to read dozens of pages (with some [[Help:Style|alien style]] applied) before they had the basic system running. On the other hand, one of the main points of BG should be to prepare the readers for other ArchWiki articles, but sometimes the readers are [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=291207&oldid=285657 too] [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=304473&oldid=295238 spoiled].<br />
:Well, that is my defence of keeping both IG and BG. In my opinion it is enough to just properly define the scope of BG and trim it down to ease the maintenance, addressing the ''content'' part. But of course if there is a suggestion on merging the two guides addressing the ''style'' issues, let's hear it!<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:16, 30 March 2014 (UTC)<br />
<br />
::About the style issue, I don't think experienced users would be so bothered by some pacman, systemctl or nano examples, and the unified guide should probably explicitly warn users that they won't find similar examples in the other articles, which would be a perfect way to invite them to become familiar with [[pacman]], [[systemd]], [[Help:Reading]]... Besides, if the guide will be properly structured, experienced users who don't have their own custom installation notes will be able to just follow the automatic ToC as a memory refresher.<br />
::I disagree that the fact that the "BG is readable ''without reading other pages''" is a good thing, as that's exactly the reason that makes it hard to maintain and encourages duplication of information; if users were used to follow links instead, most of the efforts now spent in improving the BG would be instead spent in properly improving the linked articles, which would then become as easy to follow as the BG is now.<br />
::Anyway, I've proposed a change in [[#Comments]] (under [[#Plan]]) that I think should be more likely to reach general consensus, and that would already be a good step forward.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:35, 31 March 2014 (UTC)<br />
<br />
:::I'm beginning to understand the need for merging. After the BG is slimmed down to cover only one example scenario, the title will be just wrong and the scope will be ''exactly'' the same as for IG. It all depends on whether different target audience and related style differences are enough to justify two guides.<br />
:::I hate being the blocker, so let's slim down BG and when it comes to the point of merging with IG, at least it will not be so shocking. I can't help but to think about it as simple redirecting of BG to IG, which will be (more or less) the eventual outcome, so I will need some time to absorb.<br />
:::Finally, we should also look at [[ArchWiki:Requests#Cleanup: installation category]], so that [[:Category:Getting and installing Arch]] is actually useful for providing alternative scenarios, and to ensure there is a place where to move excessive information from the BG.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 7 April 2014 (UTC)<br />
<br />
::::You are not "the blocker", every opinion is as valuable as the others if well argumented, be it for or against the proposal. Especially in this case where we seem to be the only 2 people interested in discussing...<br />
::::If the unification will eventually be completed, of course the BG will become a redirect to the IG, and the latter will be unprotected (and well watched so it's not turned again into a BG).<br />
::::Let's go on with the change very gradually, that's definitely the best way to let everyone successfully and happily adapt to the new way of following the document, which, if done properly, will be even easier and clearer (no need to compare two guides anymore, just to mention an advantage).<br />
::::Of course [[ArchWiki:Requests#Cleanup: installation category]] is strictly linked to all this, I'll try to get there too.<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:26, 9 April 2014 (UTC)<br />
<br />
:::::I personally would suggest leaving the Installation guide locked after the merger (even if that would lock me out also :). Thing is, if someone went through the effort of researching an addition to the guide, it would be easy for them to bring it up here, in the talk page, and easier for the community to discuss (and implement, if applicable). <br />
:::::Leaving the Installation guide unprotected however would make it open to hasty edits. Even if the IG were well watched as said, a made edit's context may not be sufficiently clear to "judge" it on the spot (confirmed by [[ArchWiki:Reports]]). Having contested content remain (however short) on the main, "official" installation reference is less than ideal.<br />
:::::A compromise may be similar to the [[IRC]] page, which is not protected in the technical sense, but has a warning urging users not to edit the page without prior consensus. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:30, 19 February 2015 (UTC)<br />
<br />
::::::Once upon a time, I absolutely don't even remember where, we even discussed the option of keeping the guide in a protected page, but do all the modifications in a separate open page (as if they were two "master" and "devel" branches), with the admins periodically approving and merging the unstable page into the official one. Thanks to the recently introduced [[Special:MergeHistory]] tool, this job could be easier nowadays. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:06, 20 February 2015 (UTC)<br />
<br />
:::::::That sounds like a good option. Working hypothesis: to make users accustomed to the idea, we could now add a note at the top of the BG, suggesting to first discuss changes on the talk page. After the merger this note would then point to the "development" page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:39, 16 March 2015 (UTC)<br />
<br />
::::::::I think that [[Special:MergeHistory]] is too primitive tool for this, AFAIK its only way of operation is "merge all revisions ''up to'' specified one", i.e. there is no ''cherry-picking'' of feasible revisions. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:50, 16 March 2015 (UTC)<br />
<br />
:::::::::@Alad I'm still thinking about it, I'm not sure whether having 2 protected installation guides would be too confusing. The branch method would certainly be well suited if we really ended up merging the guides into one.<br />
:::::::::@Lahwaacz The way it would work would be (''master'' is protected, contains the whole revisions history and ''will not receive direct edits'' by anyone, including admins):<br />
:::::::::# ''develop'' is initialized with a simple copy of the latest revision of ''master''<br />
:::::::::# Some users make some edits to ''develop''<br />
:::::::::# The wiki staff amends/undos ''develop'' as necessary with additional edits (like it happens now in the only branch)<br />
:::::::::# Once ''develop'' is considered in a good state, [[Special:MergeHistory]] can be used safely, no need for cherry-picking<br />
:::::::::# Go back to 1 (at this step ''develop'' is a redirect to ''master'')<br />
:::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:09, 17 March 2015 (UTC)<br />
<br />
:::::::::A simpler alternative with the same effect would be maintaining a link that points to the latest officially approved revision in the history of the article, for example in a Note in the intro. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:13, 17 March 2015 (UTC)<br />
<br />
::::::::::Take your time, it will take a lot more work to get the BG anywhere near ready for merging. A link with note sounds viable as well; we could add a table with different options below. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:08, 17 March 2015 (UTC)<br />
<br />
== Blacklisting radeon module ==<br />
<br />
Installed Arch on my laptop, during pacstrap the screen went blank, pressing SPACE, CTL+C ... didn't helped only modprobe.blacklist=radeon enabled me to go through the whole installation process.<br />
My graphic card is ATI M96 aka Mobility Radeon HD 4650.<br />
I believe this info and similar problems should be added to the beginner's guide on a Installation's Issues Troubleshooting section. I believe this is important enough to dual post and separate it from the Removing "Kernel modules" talk. p.s. I may add that this is my first desktop Linux experience--[[User:Dhead|Dhead]] ([[User talk:Dhead|talk]]) 06:20, 4 March 2013 (UTC)<br />
<br />
:The beginners' guide should not contain hardware-specific info, if the issue is common enough links can be added to [[Beginners%27_guide#Troubleshooting_boot_problems]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:40, 27 December 2014 (UTC)<br />
<br />
== Newbie here offering thoughts on what could be changed in guide ==<br />
<br />
=== General troubleshooting ===<br />
<br />
Apart from that there should be a section at the very beginning explaining how to troubleshoot your own problems. Learning dmesg -HLkd and journalctl -b etc were helpful tools for me. I also appreciated learning lsblk, lsmod, ls etc from the various articles, but a quick over view of these helpful commands on this page would help newbies like myself. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
: Sorry! Just reading over again, and realizing that I could've saved a tonne of time if I knew the problem of "a bunch of white letters clustered on my screen" was an error I could check. It usually happened when the firmware didn't support something (in my case) but telling the user what he can do when this happens helps ease the wiki hopping. I finally, finally figured out how to debug most of my own problems and I think that is the number one thing this guide should do. No offense, but it would also lessen the load on the "newbie corner" on the forums (not that I know it's loaded or not, but less is better, right?). That way no matter what's written in the guide, if it's incorrect or leads to a bad result, the user can figure out why and what to do.. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:05, 7 June 2013 (UTC)<br />
<br />
:: Another [[Keyboard_Shortcuts|useful article]] that could be mentioned (rebooting from black screens, yay!) [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 00:27, 8 June 2013 (UTC)<br />
<br />
:::Regarding your second point, [[General troubleshooting]] is in Related articles - it could be expanded there. --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:25, 2 July 2014 (UTC)<br />
<br />
=== Mounting partitions and dual-boot ===<br />
<br />
And lastly, the surprisingly tricky bit about "mounting" partitions that do not belong to you on a dual boot system. Ultimately for me what ended up working was knowing which file systems the others could read (esp in a UEFI system). These things can't just be "linked" to because even the pages linked to don't have the information. I got quite a bit of help from friends and google. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
== Gummiboot instructions are out of order. ==<br />
<br />
I'm not certain if this is the same issue as the heading "gummiboot instructions are confusing?", but I encountered this using the Beginner's guide. In "2.4 Mount the partitions", it mentions that you should mount the ESP at /boot. But then in "2.8 Chroot and configure the base system", the root is changed to the new system's mountpoint, and /boot no longer refers to the mounted ESP partition (because this was mounted in the live installation CD, in zsh). When in "2.12.2 For UEFI motherboards" I run the gummiboot install command, it errors saying that it is not a fat32 partition. Furthermore, I'm not sure if I need to actually have the initramfs files that were made during pacstrap in the actual ESP since they were installed to /boot. (My thought is they should be, because the assumption was that the ESP has actually been mounted on /boot since before pacstrap was run.) <br />
<br />
I'm not certain what to do. (I'm new, this is my first time going through this guide.) Could someone please review this? Or perhaps I made a mistake somewhere...?<br />
<br />
[[User:Tmarks|Tmarks]] ([[User talk:Tmarks|talk]]) 14:23, 11 October 2014 (UTC)<br />
<br />
: Hmmm... After that there's a command telling about mounting to {{ic|/mnt/boot}}, so people must mount it correctly to {{ic|/mnt/boot}}. But I think you are right, I's a bit confusing and we should replace preceding {{ic|/boot}} with {{ic|/mnt/boot}} -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 11:00, 15 October 2014 (UTC)<br />
<br />
::I am not sure I follow this completely; the quoted section numbers anyhow. [[Beginners' guide#For UEFI motherboards]] states "It is strongly recommended to have the EFI System Partition mounted at /boot as this is required to automatically update Gummiboot." and then "(replace) $esp with the location of your EFI System Partiton, usually /boot" right before the gummiboot install. Maybe it was updated meanwhile, do we need to adjust something? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:54, 2 January 2015 (UTC)<br />
<br />
== Hardware clock section ==<br />
<br />
The '''Hardware clock''' section instructs users to set their hardware clock to UTC time:<br />
<br />
# hwclock --systohc --utc<br />
<br />
without explaining that this will actually reset the BIOS clock setting. Users are then warned that ''Using localtime on Arch systems may lead to several known and unfixable bugs''.<br />
<br />
Question: what might those unfixable bugs be? I've been following these instructions fairly rigorously on every Arch system I've installed, but just got burned by the clock setting, as I think I spaced out and reset the BIOS clock to localtime, so outgoing mail on the system was thrown off by several hours for a couple of days until one of the users alerted me to the problem. Setting the system clock to UTC is kind of confusing, particularly for beginners. What are the unfixable bugs from doing this? If these don't actually exist I would suggest just setting the hardware clock to localtime. This allows you to check the accuracy of the RTC when snooping around in the BIOS.<br />
<br />
# hwclock --systohc --localtime<br />
<br />
And if there really are unfixable bugs, users should be told that the hardware clock is going to be set to an unfamiliar value, so they don't freak out when they go in the system setup and find that the clock is off by several hours from the time they thought it should be. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 22:33, 5 February 2015 (UTC)<br />
<br />
:[https://lists.archlinux.org//listinfo/arch-general/ arch-general] is a probably a better place to discuss this. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:47, 6 February 2015 (UTC)<br />
<br />
::OK, I added a note explaining that this command would reset the RTC clock, which is probably good enough for the Beginner's Guide. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 08:44, 6 February 2015 (UTC)<br />
<br />
:::I've just finished [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=359876&oldid=359646 expanding] that section, I hope it clarifies some of the doubts. Regarding the unspecified "several known and unfixable bugs" I second the suggestion to ask in the mailing list. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:22, 7 February 2015 (UTC)<br />
<br />
::::Thanks for making those edits -- it's much clearer now. I also like your simplification of my comment. Based on my own experience, it's important to point this out explicitly (that the BIOS clock setting will look funny) even if it is implicitly obvious, if you think about it. "Don't make me think" is not just a rule that applies to websites. <:) -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 09:52, 7 February 2015 (UTC)<br />
<br />
:::::I think the description is good, but a bit verbose for the BG (particularly as this is about booting multiple operations systems, namely Windows). [http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html ut-rc] (linked from [[Time#Time_standard]]) provides some more background, also on the "unfixable bugs".<br />
:::::I'd suggest to merge the more elaborate description to [[Time]], provide a short paragraph on Windows and localtime (and unexpected BIOS clock), and link to the above website. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:34, 22 February 2015 (UTC)<br />
<br />
::::::If you manage to merge the section into [[Time]] I think it's a good thing; I also think the external link can be kept only there: if we want to make the section brief, I'd say that what the readers need to know from the BG is only that they have to make sure the hw clock is set to UTC time and that all the other installed OSs must be set accordingly (Arch will consider the hw clock to be set to UTC by default). Then, if they want to know why, or if they want to use localtime for some reason, they can be sent to read [[Time]] to understand all the pros and the cons. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:15, 23 February 2015 (UTC)<br />
<br />
== Static IP ==<br />
<br />
I'd like to discuss whether to keep [[#Beginners' guide#Static IP]] or not. [[dhcpcd#Fallback static profile]] could easily be expanded to cover this, and most (home) routers provide DHCP by default. Having the information in [[dhcpcd]] also benefits [[Beginners' guide#Wired]] which directly links to that article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:20, 28 March 2015 (UTC)<br />
<br />
:I assume you'd replace it with a link to [[dhcpcd#Fallback static profile]], +1 from me. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:19, 29 March 2015 (UTC)<br />
<br />
:I'm -1 on this idea. Fallback is useful for headless installs, yes, but that's not a BG topic.? If a user starts configuring [[Beginners' guide#Static IP]], this means default ISO booting DHCP has failed. Making a static connection fallback only delays startup further in this case.. because DHCP will fail again first. <br />
:Sidenote: What one might consider, is open a flyspray suggesting the ISO default dhcpcd config could gain a fallback static IP config (with both 192.168.* and 10.10.* IPs/routes it would probably be reachable for the majority of routers). <s>Doing such might be considered network intrusive by some users though.</s> edit: since it would be a passive config, not really intrusive. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:57, 29 March 2015 (UTC)<br />
<br />
::Well, the idea is to change/expand the dhcpcd section first to include fallback as a sub-section. The main content would be a regular static profile, with info merged from the BG, and named [[dhcpcd#Static profile]]. I like suggesting a default config though. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:16, 29 March 2015 (UTC)<br />
<br />
:::Please drop a quick note, if you open a bug for it (I do the same). Sub-section or not, this part makes no sense for BG readers of that section imo. Moving the current dhcpcd content of the section, ok - but that's a neat seven lines including code and not really worth it. Moving the whole section comes at the expense of having it verbose incl. interface identification in [[dhcpcd]]. I'm neutral on that. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:45, 29 March 2015 (UTC)<br />
<br />
::::I also doubted if it was worth the effort, hence my asking. Still, I'd like some relation to the chroot section, if only a Tip for users to save/copy their config for later use. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:21, 1 April 2015 (UTC)<br />
<br />
:::::Good idea, added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=368819&oldid=368817]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:41, 6 April 2015 (UTC)<br />
<br />
4<br />
<br />
== Linked to 'parted' Manual doesn't list ext3 or ext4 for fs-type ==<br />
<br />
Hi guys. Recent Arch convert here. Loving it. No bloat! Noticed this during Beginners Guid install though:<br />
<br />
In the section on using parted ( [[Beginners%27_guide#Partition_schemes]] ), it links to the Gnu parted manual at [http://www.gnu.org/software/parted/manual/parted.html#mkpart http://www.gnu.org/software/parted/manual/parted.html#mkpart] for fs-types, but the (rather dated?) manual doesn't list ext3 or ext4. At this point I 'guessed' ext2 was the right choice... Only to find that LATER in the 'Beginners Guide' page it recommended ext4. Damn! Wasn't sure if I had to go back and re-do. Seemed not. But anyway, confusing for 'Beginners'. Anyway, dare not edit the wiki being an Arch noob at this point. Keep up the good work! Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 00:53, 7 April 2015 (UTC)<br />
<br />
:Yes, this is a rather confusing concept: the file system type associated to a partition is a different thing from the file system that you later use to format that partition... It's explained in a bit clearer way in [[Wikipedia:Disk_partitioning#PC_partition_types]], but we should probably explain it better here too.<br />
:In theory, using "ext2", "ext3" or "ext4" when you use {{ic|(parted) mkpart}} shouldn't make any difference at all, as they all set the same partition type code. What does make a difference is the file system you choose when you actually format the partition in [[Beginners'_guide#Create_filesystems]].<br />
:Of course it's wise to make sure the ''fs-type'' corresponds to the file system that is going to be used, but even though I've never tested it, I guess you could use e.g. "NTFS" for ''fs-type'' and still be able to format the partition with ext4 or whatever file system you want.<br />
:— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:49, 7 April 2015 (UTC)<br />
<br />
:: Oh, so for ext3/4 one should just set fs-type to ext2 in parted (etc). Lesson learnt. A one liner would be good saying something like "If you don't know any better, set fs-type to ext2 (Which is the correct option for ext2/3/4), and then format with ext4 below." -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 23:32, 7 April 2015 (UTC)<br />
<br />
:::We needed something more generic and educational, I've added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&action=historysubmit&diff=368977&oldid=368819], I hope it's clear enough, please re-open the discussion if it's not :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:17, 8 April 2015 (UTC)<br />
<br />
::::Looks great. Loving the Arch way, community, Wiki etc. Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 08:49, 8 April 2015 (UTC)<br />
<br />
::::Actually, parted 3.2 has an explicit label for ext4: {{bc|<nowiki><br />
(parted) help mkpart <br />
mkpart PART-TYPE [FS-TYPE] START END make a partition<br />
...<br />
FS-TYPE is one of: btrfs, nilfs2, </nowiki>'''ext4, ext3'''<nowiki>, ext2, fat32, fat16, hfsx, hfs+, hfs, jfs, swsusp, linux-swap(v1), linux-swap(v0),<br />
ntfs, reiserfs, hp-ufs, sun-ufs, xfs, apfs2, apfs1, asfs, amufs5, amufs4, amufs3, amufs2, amufs1, amufs0, amufs, affs7, affs6,<br />
affs5, affs4, affs3, affs2, affs1, affs0, linux-swap, linux-swap(new), linux-swap(old)<br />
...<br />
</nowiki>}}<br />
::::If they are all mapped to the same partition code is another matter, so I'm fine with the current wording. Alternatively we could leave out FS-TYPE completely, after all it is optional (but this is not reflected in the BG).<br />
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:41, 8 April 2015 (UTC)<br />
<br />
:::::Do we want to reopen and investigate this further? Thanks for reminding of the help command, however I can find many sources that seem to confirm that many Linux native file systems (but not all of the above!) map to 0x83: [http://www.win.tue.nl/~aeb/partitions/partition_types-1.html] [http://askubuntu.com/questions/230930/whats-the-difference-of-partition-type-and-filesystem-type] [http://www.tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x190.html] [http://thestarman.pcministry.com/asm/mbr/PartTypes.htm] [http://datarecovery.com/rd/hexadecimal-flags-for-partition-type/]. Unfortunately, as [[Wikipedia:Partition_type#Overview]] says, these codes are not standardized, so we won't be able to find an official reference. Last thing, quoting the [http://www.gnu.org/software/parted/manual/parted.html#mkpart manual], " fs-type is required for data partitions (i.e., non-extended partitions)", so I wouldn't leave it out as optional. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:46, 9 April 2015 (UTC)<br />
<br />
::::::The clearest would either be {{ic|mkpart primary linux}} or {{ic|mkpartfs ext4}} but I doubt either is supported... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:47, 9 April 2015 (UTC)<br />
<br />
:::::::I doubt too, I've [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=369201&oldid=368977 replaced] the link to the manual with "help mkpart". — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:21, 10 April 2015 (UTC)<br />
<br />
== "Internet" a proper name? ==<br />
<br />
Re [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&curid=14839&diff=370951&oldid=370932], there's an article on this: [[Wikipedia:Capitalization of "Internet"]]. It makes no clear case for either generic or proper name, so I'd also stick to the existing lower-case spelling. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 24 April 2015 (UTC)<br />
<br />
:I too tend to prefer the lower-case version for the same reasons as why we spell "telephone" and not "Telephone" etc., but I'm just noting that Wikipedia itself seems to use the upper-case version quite consistently throughout the articles. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:03, 25 April 2015 (UTC)<br />
<br />
== Adding a reference to Intel microcode ==<br />
<br />
[https://wiki.archlinux.org/index.php?title=Beginners%27_guide&action=historysubmit&diff=371418&oldid=371214 I added a short paragraph about CPU microcode], since installing intel-ucode is required on many modern Intel CPUs. The change was reverted, so I'm here discussing it to see what compromise we can make.<br />
<br />
Without installing the package, users will get hard-to-diagnose crashes, often in pthreads. I even got a system lockup. There's currently no obvious reference to the Microcode wiki page in anything a user installing a new system is likely to read. There is a very minor reference to it on the Bootloader page. I don't consider "Related Pages" to imply "Critical reading," and I don't know that a user installing a bootloader would bother with a related page that they don't know that they need (I sure didn't). There's another reference on the BIOS Update page, where again a user wouldn't be there if they didn't know they need to be there. Finally, the Korean language Beginners Guide includes a link to the Microcode. Then there's a bunch of references from computer model-specific pages, as you'd expect, as intel-ucode is required by lots of hardware.<br />
<br />
Worse than all this, I've been using Arch for almost a decade, and I still got bit by this issue this week! For such an important issue, I think we should be much noisier to ensure users install the package to avoid these random crashes. I'm not exaggerating when I say this package is critical. Your system will fail in bizarre and difficult-to-Google ways without it. Most recent Intel CPU users *must* install this package.<br />
<br />
I added this paragraph to the beginners guide, as it includes verbose, step-by-step instructions for how to install a new Arch system. The microcode is loaded by the bootloader, so I added the note there. Apparently Alad that's an inappropriate location, although no rationale was given in the revert message.<br />
<br />
I also added it to the Bootloader page, since I don't think "Related pages" is highlighted enough for how critical this issue is. It was also reverted there. But we can take this discussion to that page.<br />
<br />
So, what can we do to ensure users install this package and avoid random crashes? [[User:ColdPie|ColdPie]] ([[User talk:ColdPie|talk]]) 14:04, 29 April 2015 (UTC)</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Boot_loaders&diff=371419Boot loaders2015-04-27T15:11:35Z<p>ColdPie: Add a Note about loading CPU microcode, as I got bit by failing to install this.</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[es:Boot loaders]]<br />
[[ja:ブートローダー]]<br />
[[ru:Boot loaders]]<br />
[[zh-CN:Boot loaders]]<br />
{{Related articles start}}<br />
{{Related|Microcode}}<br />
{{Related articles end}}<br />
<br />
The boot loader is the first piece of software started by the [[Wikipedia:BIOS|BIOS]] or [[UEFI]]. It is responsible for loading the kernel with the wanted [[kernel parameters]], and [[mkinitcpio|initial RAM disk]] before initiating the [[Arch boot process|boot process]]. You can use [[:Category:Boot loaders|different kinds]] of bootloaders in Arch, such as [[GRUB]] and [[Syslinux]]. Some bootloaders only support BIOS or UEFI and some support both.<br />
<br />
This page contains a short introduction about bootloaders available in Arch. For detailed information see the corresponding pages of each bootloader.<br />
<br />
{{Note|Your bootloader is also responsible for loading [[Microcode|CPU microcode updates]]. Recent Intel CPUs, especially those using the Haswell architecture, require these updates to avoid program crashes. Intel microcode updates may require manual changes to your bootloader configuration. If necessary for your CPU, please install the {{Pkg|intel-ucode}} package and understand how to configure it in your bootloader. AMD CPUs require no extra packages or configuration changes. See [[Microcode]].}}<br />
<br />
== Both BIOS and UEFI boot loaders ==<br />
<br />
=== GRUB ===<br />
<br />
See [[GRUB]].<br />
<br />
=== Syslinux ===<br />
<br />
See [[Syslinux]].<br />
<br />
=== BURG ===<br />
<br />
{{Note|BURG is not officially supported by Arch developers.}}<br />
<br />
See [[BURG]].<br />
<br />
== UEFI-only boot loaders ==<br />
<br />
=== Linux Kernel EFISTUB ===<br />
<br />
The Linux kernel can be booted directly using the built-in EFI stub loader. See [[EFISTUB]].<br />
<br />
==== Gummiboot ====<br />
<br />
Gummiboot is a UEFI Boot Manager which provides a text menu for booting EFISTUB kernels. See [[Gummiboot]].<br />
<br />
==== rEFInd ====<br />
<br />
rEFInd is a UEFI Boot Manager which provides a graphical menu for booting EFISTUB kernels. See [[rEFInd]].<br />
<br />
==== Clover ====<br />
<br />
Clover is a UEFI Boot Manager which provides native resolution GUI for booting EFISTUB kernels. See [[Clover]].<br />
<br />
=== ELILO ===<br />
<br />
{{Warning|1=ELILO upstream has clarified that it is no longer in active development, meaning no new features will be added and only bug-fixes are released. See https://sourceforge.net/mailarchive/message.php?msg_id=31524008 for more information. ELILO is not officially supported by Arch developers.}}<br />
<br />
ELILO is the UEFI version of the BIOS-only [[LILO]]. Its config file {{ic|elilo.conf}} is similar to [[LILO]]'s config file. Upstream provided compiled binaries are available at http://sourceforge.net/projects/elilo/ and an AUR package at {{AUR|elilo-efi}}.<br />
<br />
== BIOS-only boot loaders ==<br />
<br />
=== GRUB Legacy ===<br />
<br />
{{Note|GRUB Legacy is not officially supported by Arch developers.}}<br />
<br />
GRUB Legacy (also known as grub-0.97), is the legacy, BIOS-only branch of [[GRUB]]. See [[GRUB Legacy]].<br />
<br />
=== LILO ===<br />
<br />
{{Note|LILO is not officially supported by Arch developers but it does continue to be actively developed.}}<br />
<br />
See [[LILO]].<br />
<br />
=== NeoGRUB ===<br />
<br />
{{Note|NeoGRUB is not officially supported by Arch developers.}}<br />
<br />
NeoGRUB provides a means to boot Arch from the Windows boot loader without installing an additional boot loader. See [[NeoGRUB]].<br />
<br />
Booting Arch from NeoGRUB has not been tested yet from Windows 8 and/or UEFI systems.<br />
<br />
== Troubleshooting ==<br />
<br />
=== UEFI boot loader does not show up in firmware menu ===<br />
<br />
On some UEFI motherboards like boards with an Intel Z77 chipset, adding entries with {{ic|efibootmgr}} or {{ic|bcfg}} from the EFI Shell will not work because they don't show up on the boot menu list after being added to NVRAM.<br />
<br />
This issue is caused because the motherboards can only load Microsoft Windows. To solve this you have to place the {{ic|.efi}} file in the location that Windows uses.<br />
<br />
Copy the {{ic|bootx64.efi}} file from the Arch Linux installation medium ({{ic|FSO:}}) to the Microsoft directory your ESP partition on your hard drive ({{ic|FS1:}}). Do this by booting into EFI shell and typing:<br />
<br />
FS1:<br />
cd EFI<br />
mkdir Microsoft<br />
cd Microsoft<br />
mkdir Boot<br />
cp FS0:\EFI\BOOT\bootx64.efi FS1:\EFI\Microsoft\Boot\bootmgfw.efi<br />
<br />
After reboot, any entries added to NVRAM should show up in the boot menu.<br />
<br />
== See also ==<br />
<br />
* [http://www.rodsbooks.com/efi-bootloaders/ Rod Smith - Managing EFI Boot Loaders for Linux]<br />
* [http://www.rodsbooks.com/refind/ Rod Smith - rEFInd, a fork or rEFIt]<br />
* [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/efi-stub.txt;hb=HEAD Linux Kernel Documentation on EFISTUB]<br />
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=291f36325f9f252bd76ef5f603995f37e453fc60;hp=55839d515495e766605d7aaabd9c2758370a8d27 Linux Kernel EFISTUB Git Commit]<br />
* [http://www.rodsbooks.com/efi-bootloaders/efistub.html Rod Smith's page on EFISTUB]<br />
* [http://www.rodsbooks.com/refind/linux.html rEFInd Documentation for booting EFISTUB Kernels]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=371418Beginners' guide2015-04-27T15:07:12Z<p>ColdPie: /* Install and configure a bootloader */ Add a Note about loading CPU microcode, as I got bit by failing to install this.</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:Beginners' Guide]]<br />
[[bg:Beginners' Guide]]<br />
[[cs:Beginners' Guide]]<br />
[[da:Beginners' Guide]]<br />
[[de:Anleitung für Einsteiger]]<br />
[[el:Beginners' Guide]]<br />
[[es:Beginners' Guide]]<br />
[[fa:راهنمای تازهکارها]]<br />
[[fr:Installation]]<br />
[[he:Beginners' Guide]]<br />
[[hr:Beginners' Guide]]<br />
[[hu:Beginners' Guide]]<br />
[[id:Beginners' Guide]]<br />
[[it:Beginners' Guide]]<br />
[[ja:ビギナーズガイド]]<br />
[[ko:Beginners' Guide]]<br />
[[lt:Beginners' Guide]]<br />
[[nl:Beginners' Guide]]<br />
[[pl:Beginners' Guide]]<br />
[[pt:Beginners' Guide]]<br />
[[ro:Ghidul începătorilor]]<br />
[[ru:Beginners' guide]]<br />
[[sk:Beginners' Guide]]<br />
[[sr:Beginners' Guide]]<br />
[[sv:Nybörjarguiden]]<br />
[[tr:Yeni başlayanlar rehberi]]<br />
[[uk:Beginners' Guide]]<br />
[[zh-CN:Beginners' guide]]<br />
[[zh-TW:Beginners' Guide]]<br />
{{Related articles start}}<br />
{{Related|:Category:Accessibility}}<br />
{{Related|Installation guide}}<br />
{{Related|Diskless system}}<br />
{{Related|Install from SSH}}<br />
{{Related|General recommendations}}<br />
{{Related|General troubleshooting}}<br />
{{Related articles end}}<br />
This document will guide you through the process of installing [[Arch Linux]] using the [https://projects.archlinux.org/arch-install-scripts.git/ Arch Install Scripts]. Before installing, you are advised to skim over the [[FAQ]].<br />
<br />
The community-maintained [[Main page|ArchWiki]] is the primary resource that should be consulted if issues arise. The [[IRC channel]] (irc://irc.freenode.net/#archlinux) and the [https://bbs.archlinux.org/ forums] are also excellent resources if an answer cannot be found elsewhere. In accordance with [[the Arch Way]], you are encouraged to type {{ic|man ''command''}} to read the [[man page]] of any command you are unfamiliar with.<br />
<br />
== Minimum system requirements ==<br />
<br />
Arch Linux should run on any [[Wikipedia:P6 (microarchitecture)|i686]] compatible machine with a minimum of 256 MB RAM. A basic installation with all packages from the {{Grp|base}} group should take less than 800 MB of disk space. If you are working with limited space, this can be trimmed down considerably, but you will have to know what you are doing.<br />
<br />
== Prepare the latest installation medium ==<br />
<br />
{{Tip|Compared to the regular ISO images, the [https://downloads.archlinux.de/iso/archboot/latest archboot] images can take several steps explained in this guide [[Archboot#Interactive_setup_features|interactively]]. See [[Archboot]] for details.}}<br />
<br />
The installation media and their [[GnuPG]] signatures can be acquired from the [https://archlinux.org/download/ Download] page. The single ISO image supports both 32bit and 64bit systems; this guide assumes you use the latest available version.<br />
<br />
It is highly recommended to verify the image signature before use, ''especially when downloading from an HTTP mirror'', as these are run by volunteers who could [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#explanation theoretically serve malicious images]. On a system with GnuPG installed, do this by downloading the ''PGP signature'' (under ''Checksums'') to the ISO directory, and run:<br />
<br />
$ gpg --verify archlinux-''version''-dual.iso.sig<br />
<br />
If the public key is not found, [[GnuPG#Import key|import]] it with {{ic|gpg --recv-keys ''key-id''}}. <br />
<br />
Alternatively, run from an existing Arch Linux installation:<br />
<br />
$ pacman-key -v archlinux-''version''-dual.iso.sig<br />
<br />
Now choose one of the methods from the table below to [[#Boot the installation medium]] on the target machine(s). As the installation process retrieves packages from a remote repository, these methods require an internet connection; see [[Offline installation of packages]] when none is available.<br />
<br />
{| class="wikitable"<br />
! Method<br />
! Articles<br />
! Conditions<br />
|-<br />
| Write the image on flash media or optical disc, then boot from it.<br />
|<br />
* [[USB flash installation media]]<br />
* [[Optical disc drive#Burning]]<br />
|<br />
* Installation on one, or a few machines at most<br />
* Obtain a directly bootable system<br />
|-<br />
| Mount the image on a server machine and have clients boot it over the network.<br />
|<br />
* [[PXE]]<br />
* [[Diskless system]]<br />
|<br />
* Client-server model<br />
* Wired (1Gbit+) network connection<br />
|-<br />
| Mount the image in a running Linux system and install Arch from a chroot environment.<br />
|<br />
* [[Install from existing Linux]]<br />
* [[Install from SSH]]<br />
|<br />
* Replace an existing system with reduced downtime<br />
* Install on the local machine, or a remote one via [[VNC]] or [[SSH]]<br />
|-<br />
| Set up a virtual machine and install Arch as a guest system.<br />
|<br />
* [[:Category:Hypervisors]]<br />
* [[Moving an existing install into (or out of) a virtual machine]]<br />
|<br />
* Operating system compatible with virtualization software<br />
* Obtain an isolated system for learning, testing or debugging<br />
|}<br />
<br />
== Boot the installation medium ==<br />
<br />
Point the current boot device to the media containing the Arch installation media. This is typically achieved by pressing a key during the [[Wikipedia:Power-on self test|POST]] phase, as indicated on the splash screen. Refer to your motherboard's manual for details.<br />
<br />
When the Arch menu appears, select "Boot Arch Linux" and press {{ic|Enter}} to enter the live environment where you will perform the actual installation. Various boot parameters (for example, {{ic|copytoram}}) can be used by editing the boot entry ({{ic|tab}} for syslinux and {{ic|e}} for gummiboot), see [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams README.bootparams] for reference.<br />
<br />
You will be presented with a [[Zsh]] shell prompt, logged in as the root user. ''Zsh'' provides advanced tab completion and other features as part of the [http://grml.org/zsh/ grml config]. For editing text files, the console editor [[nano#Usage|nano]] is suggested.<br />
<br />
=== Booting into UEFI mode ===<br />
<br />
{{Warning|While the choice to install in EFI mode is forward looking, early vendor UEFI implementations carried more bugs than their BIOS counterparts. It is advised to do a search relating your particular mainboard model before proceeding.}}<br />
<br />
In case you have a [[Unified Extensible Firmware Interface|UEFI]] motherboard with UEFI mode enabled, the CD/USB will automatically launch Arch Linux via [[Gummiboot]] and present the following menu:<br />
<br />
{{bc|<br />
Arch Linux archiso x86_64 UEFI USB<br />
UEFI Shell x86_64 v1<br />
UEFI Shell x86_64 v2<br />
EFI Default Loader}}<br />
<br />
To verify you are booted in UEFI mode, run:<br />
<br />
# efivar -l<br />
<br />
Should ''efivar'' not list the UEFI variables properly, check if all [[UEFI#Requirements_for_UEFI_variable_support|requirements]] are met.<br />
<br />
=== Troubleshooting boot problems ===<br />
<br />
* If you are using an Intel video chipset and the screen goes blank during the boot process, the problem is likely an issue with [[Kernel mode setting]]. A possible workaround may be achieved by rebooting and pressing {{ic|Tab}} over the entry that you are trying to boot (i686 or x86_64). At the end of the string type {{ic|nomodeset}} and press {{ic|Enter}}. Alternatively, try {{ic|1=video=SVIDEO-1:d}} which, if it works, will not disable kernel mode setting. You can also try {{ic|1=i915.modeset=0}}. See the [[Intel]] article for more information.<br />
* If the screen does ''not'' go blank and the boot process gets stuck while trying to load the kernel, press {{ic|Tab}} while hovering over the menu entry, type {{ic|1=acpi=off}} at the end of the string and press {{ic|Enter}}.<br />
<br />
== Keyboard layout ==<br />
<br />
{{Note|Changes here ''only'' affect the installation process.}}<br />
<br />
The default keyboard layout is set to [[Wikipedia:File:KB United States-NoAltGr.svg|US]], the [[locale]] to {{ic|en_US.UTF-8}}. To change the keyboard layout, run:<br />
<br />
# loadkeys ''layout''<br />
<br />
where ''layout'' is a two-letter [[Wikipedia:ISO 3166-1 alpha-2#Officially assigned code elements|country code]]. Use {{ic|localectl list-keymaps}} to list all available keymaps.<br />
<br />
If certain special characters appear as white squares or other symbols, you may wish to change the console font. See [[Fonts#Previewing_and_testing]] for details.<br />
<br />
== Establish an internet connection ==<br />
<br />
{{Warning|As of [http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id&#61;dee4c244254bb49d1ffa8bd7171ae9cce596d2d0 v197], udev no longer assigns network interface names according to the ''wlanX'' and ''ethX'' naming scheme. If you are coming from a different distribution or are reinstalling Arch and not aware of the new interface naming style, please do not assume that your wireless interface is named ''wlan0'', or that your wired interface is named ''eth0''. You can use the command {{ic|ip link}} to discover the names of your interfaces.}}<br />
<br />
The ''dhcpcd'' network daemon starts automatically during boot of the live system and will attempt to start a wired connection. Try to ping a server to see if a connection was established. For example, Google's webservers:<br />
<br />
{{hc|# ping -c 3 www.google.com|2=<br />
PING www.l.google.com (74.125.132.105) 56(84) bytes of data.<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=1 ttl=50 time=17.0 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=2 ttl=50 time=18.2 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=3 ttl=50 time=16.6 ms<br />
<br />
--- www.l.google.com ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2003ms<br />
rtt min/avg/max/mdev = 16.660/17.320/18.254/0.678 ms<br />
}}<br />
<br />
If you get a {{ic|ping: unknown host}} error, first check if there is an issue with your cable. If not, you will need to set up the network manually, as explained below. Once a connection is established move on to [[#Prepare the storage devices]].<br />
<br />
{{Tip|<br />
* The ''elinks'' browser is available in the live system: it can be useful for example to authenticate in RADIUS-protected networks. <br />
* The system you are going to install in this guide makes no pre-assumptions regarding network access. For an easy start after the first boot, it may be helpful to stick to the method that got you connected with the live medium and copy relevant configuration to the new system before you [[#Chroot and configure the base system]] later.}}<br />
<br />
=== Static IP ===<br />
<br />
Follow this procedure if you need to set up a wired connection via a static IP address.<br />
<br />
Identify the name of your ethernet interface:<br />
<br />
{{hc|# ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp2s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000<br />
link/ether 00:11:25:31:69:20 brd ff:ff:ff:ff:ff:ff<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000<br />
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
In this example, the ethernet interface is {{ic|enp2s0f0}}. If you are unsure, your ethernet interface is likely to start with the letter "e", and unlikely to be "lo" or start with the letter "w".<br />
<br />
See [[Network_configuration#Static_IP_address]] for required settings. Configure a static profile for ''dhcpcd'' in {{ic|/etc/dhcpcd.conf}} with your settings, for example: <br />
<br />
interface enp2s0f0<br />
static ip_address=192.168.0.10/24<br />
static routers=192.168.0.1<br />
static domain_name_servers=192.168.0.1 8.8.8.8<br />
<br />
Restart {{ic|dhcpcd.service}}:<br />
<br />
# systemctl restart dhcpcd.service<br />
<br />
You should now have a working network connection. If you do not, see [[Network configuration]] page.<br />
<br />
=== Wireless ===<br />
<br />
{{Warning|Wireless chipset firmware packages (for cards which require them) are pre-installed under {{ic|/usr/lib/firmware}} in the live environment (on CD/USB stick) '''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!''' Package installation is covered later in this guide. Ensure installation of both your wireless module and firmware before rebooting! See [[Wireless network configuration]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset.}}<br />
<br />
Use [[netctl]]'s ''wifi-menu'' to connect to a wireless network:<br />
<br />
# wifi-menu<br />
<br />
This should bring you a menu of wifi networks if your computer has only one Wi-Fi device (mostly the case in laptops).<br />
<br />
If your computer has more than one Wi-Fi device, you need to choose one and pass its interface name to ''wifi-menu''. First, identify the name of the needed interface:<br />
<br />
{{hc|# iw dev|2=<br />
phy#0<br />
Interface wlp3s0<br />
ifindex 3<br />
wdev 0x1<br />
addr 00:11:22:33:44:55<br />
type managed<br />
}}<br />
<br />
This example shows {{ic|wlp3s0}} as the only available wireless interface, for simplicity. If you are unsure, wireless interfaces are likely to start with the letter "w", and unlikely to be "lo" or start with the letter "e".<br />
<br />
Now try ''wifi-menu'' again by passing it the interface name:<br />
<br />
# wifi-menu wlp3s0<br />
<br />
See the sample configuration in [[WPA2 Enterprise#netctl]] for networks that require both a username and password.<br />
<br />
You should now have a working wireless network connection. If you do not or even failed to identify the wireless interface, see [[#Without wifi-menu]] below or the detailed [[Wireless network configuration]] page.<br />
<br />
==== Without wifi-menu ====<br />
<br />
Bring the interface up with:<br />
<br />
# ip link set wlp3s0 up<br />
<br />
To verify that the interface is up, inspect the output of the following command:<br />
<br />
{{hc|# ip link show wlp3s0|<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000<br />
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
The {{ic|UP}} in {{ic|<BROADCAST,MULTICAST,UP,LOWER_UP>}} is what indicates the interface is up, not the later {{ic|state DOWN}}.<br />
<br />
Most wireless chipsets require firmware in addition to a corresponding driver. The kernel tries to identify and load both automatically. If you get output like {{ic|SIOCSIFFLAGS: No such file or directory}}, this means you will need to manually load the firmware. If unsure, invoke ''dmesg'' to query the kernel log for a firmware request from the wireless chipset. For example, if you have an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
<br />
{{hc|<nowiki># dmesg | grep firmware</nowiki>|<br />
firmware: requesting iwlwifi-5000-1.ucode<br />
}}<br />
<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
Next, scan for available networks using {{ic|iw dev wlp3s0 scan <nowiki>|</nowiki> grep SSID}}, then connect to a network with:<br />
<br />
# wpa_supplicant -B -i wlp3s0 -c <(wpa_passphrase "''ssid''" "''psk''")<br />
<br />
You need to replace {{ic|''ssid''}} with the name of your network and {{ic|''psk''}} with your wireless password, '''leaving the quotes around the network name and password'''.<br />
<br />
Finally, you have to give your interface an IP address. This can be set manually or using dhcp:<br />
<br />
# dhcpcd wlp3s0<br />
<br />
If that does not work, issue the following commands:<br />
<br />
# echo 'ctrl_interface=DIR=/run/wpa_supplicant' > /etc/wpa_supplicant.conf<br />
# wpa_passphrase "''ssid''" "''psk''" >> /etc/wpa_supplicant.conf<br />
# ip link set ''interface'' up<br />
# wpa_supplicant -B -D nl80211,wext -c /etc/wpa_supplicant.conf -i ''interface''<br />
# dhcpcd -A ''interface''<br />
<br />
Setting the interface up at step 3 may not be needed, but does no harm in any case.<br />
<br />
=== Analog modem, ISDN, or PPPoE DSL ===<br />
<br />
For xDSL, dial-up, and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Behind a proxy server ===<br />
<br />
If you are behind a proxy server, you will need to export the {{ic|http_proxy}} and {{ic|ftp_proxy}} environment variables. See [[Proxy settings]] for more information.<br />
<br />
== Prepare the storage devices ==<br />
<br />
In this step, the storage devices that will be used by the new system will be prepared. Read [[Partitioning]] for a more general overview.<br />
<br />
{{Warning|Partitioning will destroy existing data. Before proceeding, you '''must''' backup all data that needs to be preserved.}}<br />
<br />
{{Tip|<br />
* Users intending to create stacked block devices for [[LVM]], [[disk encryption]] or [[RAID]], should keep those instructions into consideration when preparing the partitions.<br />
* If intending to install to a USB flash key, see [[Installing Arch Linux on a USB key]].}}<br />
<br />
=== Identify the devices ===<br />
<br />
The first step is to identify the devices where the new system will be installed. The following command will show all the available devices:<br />
<br />
# lsblk<br />
<br />
This will list all devices connected to your system along with their partition schemes, including that used to host and boot live Arch installation media (e.g. a USB drive). Not all devices listed will therefore be viable or appropriate mediums for installation. To filter out inappropriate results, the command can optionally be amended as follows:<br />
<br />
# lsblk | grep -v "rom\|loop\|airoot"<br />
<br />
Devices (e.g. hard disks) will be listed as {{ic|sd''x''}}, where {{ic|''x''}} is a lower-case letter starting from {{ic|a}} for the first device ({{ic|sda}}), {{ic|b}} for the second device ({{ic|sdb}}), and so on. Existing partitions on those devices will be listed as {{ic|sd''xY''}}, where {{ic|''Y''}} is a number starting from {{ic|1}} for the first partition, {{ic|2}} for the second, and so on. In the example below, only one device is available ({{ic|sda}}), and that device uses only one partition ({{ic|sda1}}):<br />
<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sda 8:0 0 80G 0 disk<br />
└─sda1 8:1 0 80G 0 part<br />
<br />
The {{ic|sd''xY''}} convention will be used in the examples provided below for partition tables, partitions, and file systems. As they are just examples, it is important to ensure that any necessary changes to device names, partition numbers, and/or partition sizes (etc.) are made. Do not just blindly copy and paste the commands.<br />
<br />
If the existing partition scheme needs not be changed, skip to [[#Create filesystems]], otherwise continue reading the following section.<br />
<br />
=== Partition table types ===<br />
<br />
If you are installing alongside an existing installation (i.e. dual-booting), a partition table will already be in use. If the devices are not partitioned, or the current partitions table or scheme needs to be changed, you will first have to determine the partition tables (one for each device) in use or to be used.<br />
<br />
{{Warning|If Arch and Windows are dual-booting from same device, then Arch '''must''' follow the same firmware boot mode and partitioning combination already used, or Windows will fail to boot. See [[Windows and Arch Dual Boot#Important information]] for more details.}}<br />
<br />
There are two types of partition table:<br />
<br />
* [[Master Boot Record| MBR]]: Intended for BIOS systems (also referred to as "msdos")<br />
* [[GUID Partition Table| GPT]]: Intended for UEFI systems<br />
<br />
Any existing partition table can be identified with the following command for each device:<br />
<br />
# parted /dev/sd''x'' print<br />
<br />
=== Partitioning tools ===<br />
<br />
For each device to be partitioned, a proper tool must be chosen according to the partition table to be used. Several partitioning tools are provided by the Arch installation medium, including:<br />
<br />
* [[parted]]: MBR and GPT<br />
* [[Partitioning#Fdisk usage summary|fdisk]], '''cfdisk''', '''sfdisk''': MBR and GPT<br />
* [[Partitioning#Gdisk usage summary|gdisk]], '''cgdisk''', '''sgdisk''': GPT<br />
<br />
{{Warning|Using a partitioning tool that is incompatible with your partition table type will likely result in the destruction of that table, along with any existing partitions/data.}}<br />
<br />
{{Tip|The devices may also be partitioned before booting the Arch installation media, possibly using alternative live systems with other partitioning tools. For example beginners might find it easier to use a graphical partitioning tool such as [[GParted]], which is also provided as a [http://gparted.sourceforge.net/livecd.php live CD] and works with both MBR and GPT partition tables.}}<br />
<br />
==== Using parted in interactive mode ====<br />
<br />
All the examples provided below make use of ''parted'', as it can be used for both BIOS/MBR and UEFI/GPT. It will be launched in ''interactive mode'', which simplifies the partitioning process and reduces unnecessary repetition by automatically applying all partitioning commands to the specified device.<br />
<br />
In order to start operating on a device, execute:<br />
<br />
# parted /dev/sd''x''<br />
<br />
You will notice that the command-line prompt changes from a hash ({{ic|#}}) to {{ic|(parted)}}: this also means that the new prompt is not a command to be manually entered when running the commands in the examples.<br />
<br />
To see a list of the available commands, enter:<br />
<br />
(parted) help<br />
<br />
When finished, or if wishing to implement a partition table or scheme for another device, exit from parted with:<br />
<br />
(parted) quit<br />
<br />
After exiting, the command-line prompt will change back to {{ic|#}}.<br />
<br />
=== Create new partition table ===<br />
<br />
You need to (re)create the partition table of a device when it has never been partitioned before, or when you want to change the type of its partition table. Recreating the partition table of a device is also useful when the partition scheme needs to be restructured from scratch.<br />
<br />
{{Warning|<br />
* If dual-booting with an existing installation of Windows on a UEFI/GPT system, do not erase the partition table. Doing so will destroy all existing data on the device, including the UEFI partition with the Windows ''.efi'' file required to boot it.<br />
* MBR is designed specifically for use with BIOS systems, and GPT is designed for UEFI. It is not recommended for less experienced users to break this convention as both have features and/or limitations that may be incompatible with your hardware (e.g. MBR cannot cope with devices larger than 2 TiB). [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/] If for any reason you do not wish to follow this convention, see [http://mjg59.dreamwidth.org/8035.html] and [http://rodsbooks.com/gdisk/bios.html] for more information and possible workarounds.}}<br />
<br />
Open each device whose partition table must be (re)created with:<br />
<br />
# parted /dev/sd''x''<br />
<br />
To then create a new MBR/msdos partition table for BIOS systems, use the following command:<br />
<br />
(parted) mklabel msdos<br />
<br />
To create a new GPT partition table for UEFI systems instead, use:<br />
<br />
(parted) mklabel gpt<br />
<br />
=== Partition schemes ===<br />
<br />
You can decide the number and size of the partitions the devices should be split into, and which directories will be used to mount the partitions in the installed system (also known as ''mount points''). The mapping from partitions to directories is the [[Partitioning#Partition scheme|partition scheme]], which must comply with the following requirements:<br />
<br />
* At least a partition for the {{ic|/}} (''root'') directory '''must''' be created.<br />
* Depending on the motherboard's firmware interface, the chosen [[#Partition table types]], and in some cases also the chosen [[boot loader]], the following additional partitions '''must''' be created:<br />
** '''BIOS/MBR''': no additional partition required.<br />
** '''UEFI/GPT''': one [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]].<br />
<br />
In the examples below it is assumed that a new and contiguous partitioning scheme is applied to a single device. Some optional partitions will also be created for the {{ic|/boot}} and {{ic|/home}} directories: see also [[Arch filesystem hierarchy]] for an explanation of the purpose of the various directories; if separate partitions for directories like {{ic|/boot}} or {{ic|/home}} are not created, these will simply be contained in the {{ic|/}} partition. Also the creation of an optional partiton for [[swap space]] will be illustrated.<br />
<br />
If not already open in a ''parted'' interactive session, open each device to be partitioned with:<br />
<br />
# parted /dev/sd''x''<br />
<br />
The following command will be used to create partitions:<br />
<br />
(parted) mkpart ''part-type'' ''fs-type'' ''start'' ''end''<br />
<br />
* {{ic|''part-type''}} is one of {{ic|primary}}, {{ic|extended}} or {{ic|logical}}, and is meaningful only for MBR partition tables.<br />
* {{ic|''fs-type''}} is an identifier chosen among those listed by entering {{ic|help mkpart}} as the closest match to the file system that you will use in [[#Create filesystems]]. The ''mkpart'' command does not actually create the file system: the {{ic|''fs-type''}} parameter will simply be used by ''parted'' to set a 1-byte code that is used by boot loaders to "preview" what kind of data is found in the partition, and act accordingly if necessary. See also [[Wikipedia:Disk partitioning#PC partition types]].<br />
: {{Tip|Most [[Wikipedia:File_system#Linux|Linux native file systems]] map to the same partition code ([[Wikipedia:Partition type#PID_83h|0x83]]), so it is perfectly safe to e.g. use {{ic|ext2}} for an ''ext4''-formatted partition.}}<br />
* {{ic|''start''}} is the beginning of the partition from the start of the device. It consists of a number followed by a [http://www.gnu.org/software/parted/manual/parted.html#unit unit], for example {{ic|1M}} means start at 1MiB.<br />
* {{ic|''end''}} is the end of the partition from the start of the device (''not'' from the {{ic|''start''}} value). It has the same syntax as {{ic|''start''}}, for example {{ic|100%}} means end at the end of the device (use all the remaining space).<br />
<br />
{{Warning|It is important that the partitions do not overlap each other: if you do not want to leave unused space in the device, make sure that each partition starts where the previous one ends.}}<br />
<br />
{{Note|''parted'' may issue a warning like:<br />
<br />
Warning: The resulting partition is not properly aligned for best performance.<br />
Ignore/Cancel?<br />
<br />
In this case, read [[Partitioning#Partition alignment]] and follow [[GNU Parted#Alignment]] to fix it.}}<br />
<br />
The following command will be used to flag the partition that contains the {{ic|/boot}} directory as bootable:<br />
<br />
(parted) set ''partition'' boot on<br />
<br />
* {{ic|''partition''}} is the number of the partition to be flagged (see the output of the {{ic|print}} command).<br />
<br />
==== UEFI/GPT examples ====<br />
<br />
In every instance, a special bootable [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] is required.<br />
<br />
{{Warning|If dual-booting with an existing installation of Windows on a UEFI/GPT system, the existing UEFI partition must not be deleted. Doing so will destroy the ''.efi'' file required to boot Windows.}}<br />
<br />
If creating a new EFI System Partition, use the following commands (the recommended size is 512MiB):<br />
<br />
(parted) mkpart ESP fat32 1MiB 513MiB<br />
(parted) set 1 boot on<br />
<br />
The remaining partition scheme is entirely up to you. For one other partition using 100% of remaining space:<br />
<br />
(parted) mkpart primary ext3 513MiB 100%<br />
<br />
For separate {{ic|/}} (20GiB) and {{ic|/home}} (all remaining space) partitions:<br />
<br />
(parted) mkpart primary ext3 513MiB 20.5GiB<br />
(parted) mkpart primary ext3 20.5GiB 100%<br />
<br />
And for separate {{ic|/}} (20GiB), swap (4GiB), and {{ic|/home}} (all remaining space) partitions:<br />
<br />
(parted) mkpart primary ext3 513MiB 20.5GiB<br />
(parted) mkpart primary linux-swap 20.5GiB 24.5GiB<br />
(parted) mkpart primary ext3 24.5GiB 100%<br />
<br />
==== BIOS/MBR examples ====<br />
<br />
For a minimum single primary partition using all available disk space, the following command would be used:<br />
<br />
(parted) mkpart primary ext3 1MiB 100%<br />
(parted) set 1 boot on<br />
<br />
In the following instance, a 20GiB {{ic|/}} partition will be created, followed by a {{ic|/home}} partition using all the remaining space:<br />
<br />
(parted) mkpart primary ext3 1MiB 20GiB<br />
(parted) set 1 boot on<br />
(parted) mkpart primary ext3 20GiB 100%<br />
<br />
In the final example below, separate {{ic|/boot}} (100MiB), {{ic|/}} (20GiB), swap (4GiB), and {{ic|/home}} (all remaining space) partitions will be created:<br />
<br />
(parted) mkpart primary ext3 1MiB 100MiB<br />
(parted) set 1 boot on<br />
(parted) mkpart primary ext3 100MiB 20GiB<br />
(parted) mkpart primary linux-swap 20GiB 24GiB<br />
(parted) mkpart primary ext3 24GiB 100%<br />
<br />
=== Create filesystems ===<br />
<br />
Once the partitions have been created, each must be formatted with an appropriate [[file system]], ''except'' for swap partitions. All available partitions on the intended installation device can be listed with the following command:<br />
<br />
# lsblk /dev/sd''x''<br />
<br />
With the exceptions noted below, it is recommended to use the {{ic|ext4}} file system:<br />
<br />
# mkfs.ext4 /dev/sd''xY''<br />
<br />
{{Warning|<br />
* If dual-booting with an existing installation of Windows on a UEFI/GPT system, do not re-format the UEFI partition. Doing so will destroy all existing data on that partition, including the Windows ''.efi'' file required to boot it.<br />
* If a new UEFI system partition has been created on a UEFI/GPT system, it must be formatted with a {{ic|fat32}} or {{ic|vfat32}} file system. Failure to do so will result in an unbootable installation:<br />
:{{bc|# mkfs.vfat -F32 /dev/sd''xY''}}}}<br />
<br />
=== Activate swap ===<br />
<br />
If a swap partition has been created, it must be set up and activated with:<br />
<br />
# mkswap /dev/sd''xY''<br />
# swapon /dev/sd''xY''<br />
<br />
=== Mount the partitions ===<br />
<br />
{{Note|Swap partitions must '''not''' be mounted here.}}<br />
<br />
The {{ic|/}} (root) partition must be mounted '''first''': this is because any directories such as {{ic|/boot}} or {{ic|/home}} that have separate partitions will have to be created in the root file system. The {{ic|/mnt}} directory of the live system will be used to mount the root partition, and consequently all the other partitions will stem from there. If the root partition's name is {{ic|sd''xR''}}, do:<br />
<br />
# mount /dev/sd''xR'' /mnt<br />
<br />
Once the {{ic|/}} partition has been mounted, any remaining partitions may be mounted in any order. The general procedure is to first create the mount point, and then mount the partition to it. If using a separate {{ic|/boot}} partition:<br />
<br />
# mkdir -p /mnt/boot<br />
# mount /dev/sd''xB'' /mnt/boot<br />
<br />
{{Note|Using {{ic|/boot}} is recommended also for mounting the EFI System Partition on UEFI/GPT system. See [[EFISTUB]] and related articles for alternatives.}}<br />
<br />
If using a separate {{ic|/home}} partition:<br />
<br />
# mkdir -p /mnt/home<br />
# mount /dev/sd''xH'' /mnt/home<br />
<br />
Once all the remaining partitions, if any, have been mounted, the devices are ready to install Arch.<br />
<br />
== Select a mirror ==<br />
<br />
You may want to edit the {{ic|mirrorlist}} file and place your preferred mirror first. A copy of this file will be installed on your new system by ''pacstrap'' as well, so it is worth getting it right.<br />
<br />
{{hc|# nano /etc/pacman.d/mirrorlist|<br />
##<br />
## Arch Linux repository mirrorlist<br />
## Sorted by mirror score from mirror status page<br />
## Generated on YYYY-MM-DD<br />
##<br />
<br />
<nowiki>Server = http://mirror.example.xyz/archlinux/$repo/os/$arch</nowiki><br />
...}}<br />
<br />
If you want, you can make it the ''only'' mirror available by deleting all other lines, but it is usually a good idea to have a few more, in case the first one goes offline. Should you change your mirror list at a later stage, refresh all package lists with {{ic|pacman -Syyu}}. See [[Mirrors]] for more information.<br />
<br />
== Install the base system ==<br />
<br />
The base system is installed using the ''pacstrap'' script. The {{ic|-i}} switch can be omitted if you wish to install every package from the {{Grp|base}} group without prompting. To build packages from the [[AUR]] or with [[ABS]], you will also need the {{Grp|base-devel}} group.<br />
<br />
# pacstrap -i /mnt base base-devel<br />
<br />
Other packages can be installed later using [[pacman]].<br />
<br />
See [[Pacman#Troubleshooting]] and [[Pacman-key#Troubleshooting]] in case of errors.<br />
<br />
== Generate an fstab ==<br />
<br />
[[Wikipedia:Universally_unique_identifier|UUID]]s are used because they have certain advantages (see [[fstab#Identifying filesystems]]). If you prefer labels instead, replace the {{ic|-U}} option with {{ic|-L}}:<br />
<br />
# genfstab -U -p /mnt >> /mnt/etc/fstab<br />
# nano /mnt/etc/fstab<br />
<br />
{{Warning|The {{ic|fstab}} file should always be checked after generating it. If you encounter errors running ''genfstab'' or later in the install process, do '''not''' run ''genfstab'' again; just edit the {{ic|fstab}} file. See [[fstab#Field definitions]] for syntax information.}}<br />
<br />
== Chroot and configure the base system ==<br />
<br />
Next, [[Change root|chroot]] into your newly installed system:<br />
<br />
# arch-chroot /mnt /bin/bash<br />
<br />
At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system. These can either be created if they do not exist, or edited if you wish to change the defaults.<br />
<br />
Closely following and understanding these steps is of key importance to ensure a properly configured system.<br />
<br />
{{Warning|Do not assume that the tools you used from the ISO are automatically installed. For example, if you used ''wifi-menu'' to gain network access during the installation and want to continue so after the first boot, you will have to install ''dialog'' to use it. The following section specifies such cases, do follow it closely to avoid a hiccup in your fresh install.}}<br />
<br />
=== Locale ===<br />
<br />
Locales define which language the system uses and other regional considerations, such as currency denomination, numerology and character sets. Possible values are listed in {{ic|/etc/locale.gen}}, with the active locale defined in {{ic|locale.conf}} files.<br />
<br />
All entries in {{ic|locale.gen}} are commented out (preceded by {{ic|#}}) by default. Uncomment {{ic|en_US.UTF-8 UTF-8}}, as well as other needed localisations. {{ic|UTF-8}} is highly recommended over other options.<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
...<br />
#en_SG ISO-8859-1<br />
en_US.UTF-8 UTF-8<br />
#en_US ISO-8859-1<br />
...<br />
}}<br />
<br />
Before locales can be enabled, they must be ''generated'':<br />
<br />
# locale-gen<br />
<br />
Create {{ic|/etc/locale.conf}}, where {{ic|LANG}} refers to the first column of an uncommented entry in {{ic|/etc/locale.gen}}.<br />
<br />
# echo LANG=''en_US.UTF-8'' > /etc/locale.conf<br />
<br />
Export the chosen locale:<br />
<br />
# export LANG=''en_US.UTF-8''<br />
<br />
{{Note|<br />
* Choosing {{ic|en_US.UTF-8}} as the system locale allows to keep system logs in English for easier troubleshooting. Users may override this setting for their session as described in [[Locale#Setting the locale]].<br />
* {{ic|LANG}} acts as the default value for the locale-related {{ic|LC_*}} variables. To use other locales for these variables, run ''locale'' to see the available options and add them to {{ic|locale.conf}}. It is not recommended to set the {{ic|LC_ALL}} variable. See [[Locale]] for details.}}<br />
<br />
=== Console font and keymap ===<br />
<br />
If you changed the default console keymap and font in [[#Keyboard layout]], create {{ic|/etc/vconsole.conf}} to make those changes persist in the installed system. It is important {{ic|KEYMAP}} matches the value initially set with {{ic|loadkeys}}, to ensure correct entry of [[#Set the root password|the root password]] on reboot.<br />
<br />
{{hc|# nano /etc/vconsole.conf|2=<br />
KEYMAP=''de-latin1''<br />
FONT=''lat9w-16''<br />
}}<br />
<br />
These settings only apply to virtual consoles, not [[Xorg]]. See [[Fonts#Console fonts]] for more information.<br />
<br />
=== Time zone ===<br />
<br />
Available time zones and subzones can be found in the {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}} directories, and listed with the ''ls'' command. Create a symbolic link {{ic|/etc/localtime}} to your subzone file {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}}:<br />
<br />
# ln -s /usr/share/zoneinfo/''Zone''/''SubZone'' /etc/localtime<br />
<br />
You may use [http://tldp.org/LDP/abs/html/tabexpansion.html tab completion] to show available zones and subzones. Example:<br />
<br />
# ln -s /usr/share/zoneinfo/Europe/Minsk /etc/localtime<br />
<br />
If you get {{ic|ln: failed to create symbolic link '/etc/localtime': File exists}}, check the existing file with {{ic|ls -l /etc/localtime}} and add the {{ic|-f}} option to the ''ln'' command to overwrite it.<br />
<br />
=== Hardware clock ===<br />
<br />
If you have multiple operating systems installed in the same machine, they will all derive the current time from the same hardware clock, which must be set to either UTC or ''localtime''. For this reason you must make sure that all the operating systems see the hardware clock as providing time in the same chosen [[Time#Time standard|standard]], otherwise some of them will perform the time zone adjustement for the system clock, while others will not.<br />
<br />
In particular, it is strongly recommended to set the hardware clock to UTC, in order to avoid conflicts between the installed operating systems. For example, if the hardware clock was set to ''localtime'', more than one operating system may adjust it after a [[Wikipedia:Daylight_saving_time|DST]] change, thus resulting in an overcorrection; more problems may arise when travelling between different time zones and using one of the operating systems to reset the system/hardware clock.<br />
<br />
To set the hardware clock to UTC in Linux, run:<br />
<br />
# hwclock --systohc --utc<br />
<br />
The ''hwclock'' command also generates the {{ic|/etc/adjtime}} file.<br />
<br />
{{Note|Using UTC for the hardware clock does not mean that software will display time in UTC. However, the system setup/BIOS interface will instead: this should be neither surprising nor treated as a bug.}}<br />
<br />
{{Warning|Windows systems use ''localtime'' by default. Using ''localtime'' on Arch systems may lead to several known and unfixable bugs, but there are no plans to drop support for ''localtime''. It is, though, recommended to set Windows to use UTC instead, and prevent it from synchronising time. See [[Time#UTC in Windows]].}}<br />
<br />
=== Kernel modules ===<br />
<br />
Needed kernel modules are automatically loaded by [[udev]], so you will rarely need to load modules manually. See [[Kernel modules]] for details.<br />
<br />
=== Hostname ===<br />
<br />
Set the [[Network_configuration#Set_the_hostname|hostname]] to your liking:<br />
<br />
# echo ''myhostname'' > /etc/hostname<br />
<br />
Add the same hostname to {{ic|/etc/hosts}}:<br />
<br />
#<ip-address> <hostname.domain.org> <hostname><br />
127.0.0.1 localhost.localdomain localhost ''myhostname''<br />
::1 localhost.localdomain localhost ''myhostname''<br />
<br />
=== Configure the network ===<br />
<br />
You need to configure the network again, but this time for your newly installed environment. The procedure and prerequisites are similar to the one described [[#Establish an internet connection|above]], except we are going to make it persistent and automatically run at boot.<br />
<br />
As a first step, identify the network interface name you want to configure the connection for with {{ic|ip link}}.<br />
<br />
{{Note|<br />
* For more in-depth information on network configuration, visit [[Network configuration]] and [[Wireless network configuration]].<br />
* If you would like to use the old interface naming scheme (i.e. {{ic|eth''X''}} and {{ic|wlan''X''}}) you can accomplish this by creating an empty file at {{ic|/etc/udev/rules.d/80-net-setup-link.rules}} which will mask the file of the same name located under {{ic|/usr/lib/udev/rules.d}}.<br />
}}<br />
<br />
Now select a daemon to handle the configuration and operation. Several are listed below; only select '''one''' of them for the new system.<br />
<br />
==== Wired ====<br />
<br />
; Using dhcpcd<br />
A simple option for adapter configuration is to use the DHCP Client Daemon, the method used by default with the install medium. See [[Dhcpcd#Running]].<br />
<br />
Users requiring only '''single wired network connection''' can simply enable the ''dhcpcd'' service for the interface:<br />
<br />
# systemctl enable dhcpcd@''interface_name''.service<br />
<br />
If static IP settings are required, adjust the profile configuration as described in [[#Static IP]]. <br />
<br />
; Using systemd-networkd<br />
<br />
The Arch default init system, [[systemd]] includes built-in support for managing adapters using both DHCP and static IP setups. Configuration is simple. See [[Systemd-networkd#Required_services_and_setup]].<br />
<br />
; Using netctl<br />
<br />
Another option is [[netctl]] which is a CLI-based tool used to configure and manage network connections via user-created profiles. Create a profile as shown in [[netctl#Example profiles]], then enable it as described in [[netctl#Basic method]].<br />
<br />
==== Wireless ====<br />
<br />
All of the tools listed in [[#Wired]] above can activate wireless connections. For wireless, however, ''dhcpcd'' and ''systemd-networkd'' require a separate configuration of the connection in the wireless backend, [[wpa_supplicant]], first. If you anticipate to connect the machine to different wireless networks over time, a tool which provides its own connection management may be easier to handle. Aside from [[netctl]] introduced below, [[Wireless network configuration#Automatic setup]] lists other choices. <br />
<br />
{{Note|If your wireless adapter requires a firmware (as described in the above [[#Wireless|Establish an internet connection]] section and also in the article [[Wireless network configuration#Device driver]]), install the package containing your firmware. Most of the time, the {{Pkg|linux-firmware}} package will contain the needed firmware. Though for some devices, the required firmware might be in its own package. For example:<br />
{{bc|# pacman -S zd1211-firmware}}<br />
See [[Wireless network configuration#Installing driver/firmware]] for more info.}}<br />
<br />
Install {{Pkg|iw}} and {{Pkg|wpa_supplicant}} which you will need to connect to a network:<br />
<br />
# pacman -S iw wpa_supplicant<br />
<br />
===== Adding wireless networks =====<br />
<br />
; Using wifi-menu<br />
<br />
Install {{Pkg|dialog}}, which is required for ''wifi-menu'':<br />
<br />
# pacman -S dialog<br />
<br />
After finishing the rest of this installation and rebooting, you can connect to the network with:<br />
<br />
# wifi-menu ''interface_name''<br />
<br />
Where {{ic|''interface_name''}} is the interface of your wireless chipset.<br />
<br />
{{Warning|Do not use ''wifi-menu'' now, instead wait until you have finished this guide and have rebooted. It will not work now because a process spawned by this command will conflict with the one you have running outside of the chroot. Alternatively, you could just configure a network profile manually using the following templates so that you do not have to worry about using ''wifi-menu'' at all.}}<br />
<br />
; Using manual netctl profiles<br />
<br />
Copy a network profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/wireless-wpa my-network<br />
<br />
Edit the profile as needed (modify {{ic|Interface}}, {{ic|ESSID}} and {{ic|Key}}):<br />
<br />
# nano my-network<br />
<br />
Enable above created profile to start it at every boot:<br />
<br />
# netctl enable my-network<br />
<br />
===== Connect automatically to known networks =====<br />
<br />
{{Warning|This method cannot be used with explicitely enabled [[Netctl#Configuration|profiles]], i.e. through {{ic|netctl enable ''profile''}}.}}<br />
<br />
Install {{Pkg|wpa_actiond}}, which is required for {{ic|netctl-auto}}:<br />
<br />
# pacman -S wpa_actiond<br />
<br />
Enable the {{ic|netctl-auto}} service, which will connect to known networks and gracefully handle roaming and disconnects:<br />
<br />
# systemctl enable netctl-auto@''interface_name''.service<br />
<br />
{{Tip|[[netctl]] also provides {{ic|netctl-ifplugd}}, which can be used to handle wired profiles in conjunction with {{ic|netctl-auto}}.}}<br />
<br />
==== Analog modem, ISDN or PPPoE DSL ====<br />
<br />
For xDSL, dial-up and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Create an initial ramdisk environment ===<br />
<br />
{{Note|As [[mkinitcpio]] was run on installation of {{Pkg|linux}} with ''pacstrap'', most users can skip this step and use the defaults provided in {{ic|mkinitcpio.conf}}.}}<br />
<br />
Set the correct [[Mkinitcpio#HOOKS|hooks]] in {{ic|/etc/mkinitcpio.conf}} and re-generate the initramfs image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
=== Set the root password ===<br />
<br />
Set the root password with:<br />
<br />
# passwd<br />
<br />
=== Install and configure a bootloader ===<br />
<br />
{{Note|Your bootloader is also responsible for loading [[Microcode|CPU microcode updates]]. Recent Intel CPUs, especially those using the Haswell architecture, require these updates to avoid program crashes. Intel microcode updates may require manual changes to your bootloader configuration. If necessary for your CPU, please install the {{Pkg|intel-ucode}} package and understand how to configure it in your bootloader. AMD CPUs require no extra packages or configuration changes. See [[Microcode]].}}<br />
<br />
==== For BIOS motherboards ====<br />
<br />
For BIOS systems, several boot loaders are available, see [[Boot loaders]] for a complete list. Choose one as per your convenience. Possible choices include:<br />
<br />
* [[Syslinux#Installation]] is (currently) limited to loading only files from the partition where it was installed. Its configuration file is considered to be easier to understand. An example configuration can be found in [[Syslinux#Examples]].<br />
* [[GRUB]] is more feature-rich and supports more complex scenarios. Its configuration file(s) is more similar to 'sh' scripting language, which may be difficult for beginners to manually write. It is recommended that they automatically generate one.<br />
<br />
Here, installation with '''GRUB''' and '''MBR''' is demonstrated. <br />
<br />
Install the {{Pkg|grub}} package; to have GRUB search for other installed operating systems, install {{Pkg|os-prober}} in addition:<br />
<br />
# pacman -S grub os-prober<br />
<br />
Install the bootloader to the drive Arch was installed to (do '''not''' append a partition number, or {{ic|/dev/sda''X''}}):<br />
<br />
# grub-install --target=i386-pc --recheck ''/dev/sda''<br />
<br />
Automatically generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|A sample {{ic|/boot/grub/grub.cfg}} is included with the {{Pkg|grub}} package, and subsequent {{ic|grub-*}} commands may not over-write it. Ensure your intended changes are in {{ic|grub.cfg}}, rather than in {{ic|grub.cfg.new}} or similar file.}}<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
==== For UEFI motherboards ====<br />
<br />
For UEFI systems, several boot loaders are available, see [[Boot loaders]] for a complete list. Choose one as per your convenience. Possible choices include:<br />
<br />
* [[gummiboot]] is a minimal UEFI Boot Manager which provides a menu for [[EFISTUB]] kernels and other UEFI applications. This is recommended for beginners, especially those wishing to dual-boot with other installed operating systems such as Windows 8.<br />
* [[GRUB#UEFI_systems|GRUB]] is a more complete bootloader, useful if you run into problems with Gummiboot.<br />
<br />
Here, installation with ''gummiboot'' is demonstrated. First install {{Pkg|dosfstools}} to manipulate the EFI System Partition post-installation, and {{Pkg|efibootmgr}} to create a UEFI boot entry (used by bootmanager installation scripts):<br />
<br />
# pacman -S dosfstools efibootmgr<br />
<br />
{{Note|<br />
* For UEFI boot, the drive needs to be GPT-partitioned and an [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] (512 MiB or larger, gdisk type {{ic|EF00}}, formatted with FAT32) must be present. In the following examples, this partition is assumed to be mounted at {{ic|/boot}}. If you have followed this guide from the beginning, you have already done all of these.<br />
* It is strongly recommended to have the EFI System Partition mounted at {{ic|/boot}} as this is required to automatically update Gummiboot.<br />
}}<br />
<br />
Install the {{Pkg|gummiboot}} package and run the automated installation script, replacing {{ic|'''$esp'''}} with the location of your EFI System Partiton, usually {{ic|/boot}}:<br />
<br />
# pacman -S gummiboot<br />
# gummiboot --path='''$esp''' install<br />
<br />
Gummiboot will automatically be detected by firmware that requires that the bootable {{ic|bootx64.efi}} stub be placed in {{ic|'''$esp'''/EFI/boot}}, and will in turn automatically detect the presence of any other installed operating systems using ''.efi'' stubs. However, it will still be necessary to manually create a configuration file for Gummiboot.<br />
<br />
First, create {{ic|'''$esp'''/loader/entries/arch.conf}} and add the following, replacing {{ic|/dev/sdaX}} with your '''root''' partition (most likely {{ic|/dev/sda2}} if {{ic|/dev/sda1}} is the ESP):<br />
<br />
{{hc|# nano '''$esp'''/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root='''/dev/sdaX''' rw<br />
}}<br />
<br />
Second, create {{ic|'''$esp'''/loader/loader.conf}} and add the following, replacing the timeout value (in seconds) with your own choice:<br />
{{hc|# nano '''$esp'''/loader/loader.conf|2=<br />
default arch<br />
timeout 5<br />
}}<br />
<br />
See [[gummiboot]] for more information.<br />
<br />
== Unmount the partitions and reboot ==<br />
<br />
Exit from the chroot environment:<br />
<br />
# exit<br />
<br />
{{Note|While partitions are unmounted automatically by ''systemd'' on shutdown, you may do so manually with {{ic|umount -R /mnt}} as a safety measure. If the partition is "busy", you can find the cause with [[fuser]].}}<br />
<br />
Reboot the computer:<br />
<br />
# reboot<br />
<br />
Remove the installation media, or you may boot back into it. You can log into your new installation as ''root'', using the password you specified with ''passwd''.<br />
<br />
== Post-installation ==<br />
<br />
Your new Arch Linux base system is now a functional GNU/Linux environment ready to be built into whatever you wish or require for your purposes. You are now ''strongly'' advised to read the [[General recommendations]] article, especially the first two sections. Its other sections provide links to post-installation tutorials like setting up a graphical user interface, sound or a touchpad.<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>ColdPiehttps://wiki.archlinux.org/index.php?title=SLiM&diff=369245SLiM2015-04-10T20:29:21Z<p>ColdPie: Replace dead link with archive link.</p>
<hr />
<div>[[Category:Display managers]]<br />
[[cs:SLiM]]<br />
[[es:SLiM]]<br />
[[fr:SLiM]]<br />
[[hu:SLiM]]<br />
[[it:SLiM]]<br />
[[ja:SLiM]]<br />
[[ko:SLiM]]<br />
[[pt:SLiM]]<br />
[[ru:SLiM]]<br />
[[sk:SLiM]]<br />
[[tr:SLiM]]<br />
[[zh-CN:SLiM]]<br />
[[zh-TW:SLiM]]<br />
{{Related articles start}}<br />
{{Related|Display manager}}<br />
{{Related articles end}}<br />
{{Warning|The SliM project has been abandoned (the [http://slim.berlios.de/ project homepage] is down, leaving a [https://github.com/data-modul/slim github mirror]), and is not fully compatible to [[systemd]], including ''logind'' sessions. Consider using a different [[Display manager]] or [[Xinitrc]].}}<br />
<br />
[http://sourceforge.net/projects/slim.berlios/ SLiM] is an acronym for '''S'''imple '''L'''og'''i'''n '''M'''anager. Lightweight and easily configurable, SLiM requires minimal dependencies, and none from the [[GNOME]] or [[KDE]] desktop environments. It therefore contributes towards a lightweight system for users that also like to use lightweight desktops such as [[Xfce]], [[Openbox]], and [[Fluxbox]].<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] {{pkg|slim}} from the [[official repositories]].<br />
<br />
== Configuration ==<br />
<br />
{{Note|SLiM no longer supports a 'default' session where multiple sessions have been enabled. This is most noticable where attempting to log out and back in again to the same session.}}<br />
<br />
As of version '''1.3.6-2''', SLiM can automatically detect installed desktop environments and window managers. This is achieved through the use of {{ic|sessiondir /usr/share/xsessions/}} in {{ic|/etc/slim.conf}}. It will therefore be necessary for those who installed an earlier version of SLiM to amend {{ic|/etc/slim.conf}} and [[xinitrc]], accordingly.<br />
<br />
=== Enabling SLiM ===<br />
<br />
{{Note|{{pkg|slim}} relies on ''systemd-logind''.}}<br />
<br />
[[Systemd#Using units|Enable]] the SLiM service {{ic|slim.service}}. This assumes a previously enabled display manager was disabled first. Otherwise, change the [[Systemd#Change_default_target_to_boot_into|default target]].<br />
<br />
=== Environments ===<br />
<br />
{{Accuracy|Contradicts [[#Configuration]], are these instructions for earlier versions?}}<br />
<br />
{{Note|Available sessions for selection can be cycled through by pressing the '''F1''' key.}}<br />
<br />
{{tip|Users that have installed a previous version of SLiM can replace {{ic|session}} with a hashed {{ic|sessiondir /usr/share/xsessions/}}}}<br />
<br />
To configure SLiM 1.3.6-2 (or later) to load a particular environment, it will be necessary to edit both {{ic|/etc/slim.conf}} and {{ic|~/.xinitrc}}.<br />
<br />
First, edit {{ic|/etc/slim.conf}} in order to hash out {{ic|sessiondir /usr/share/xsessions/}}. This will consequently disable automatic detection of installed environments:<br />
<br />
# Set directory that contains the xsessions.<br />
# slim reads xsesion from this directory, and be able to select.<br />
# sessiondir /usr/share/xsessions/<br />
<br />
Users who installed a prior version of SLiM will have to replace {{ic|sessions}} with the new command.<br />
<br />
Second, edit [[xinitrc]].<br />
<br />
Users who installed a prior version of SLiM will have to replace {{ic|case $1 in [...] esac}}, where used. To clarify, below is an example of the deprecated method to select multiple sessions. The entire code provided below would simply be replaced with {{ic|exec $1}}:<br />
<br />
DEFAULTSESSION=openbox-session<br />
<br />
case "$1" in<br />
openbox) exec openbox-session ;;<br />
xfce) exec xfce4-session ;;<br />
gnome3) exec gnome-session ;;<br />
kde) exec startkde ;;<br />
cinnamon) exec gnome-session-cinnamon ;;<br />
razor-qt) exec razor-session ;;<br />
lxde) exec lxsession ;;<br />
mate) exec mate-session ;;<br />
*) exec $DEFAULTSESSION ;;<br />
esac<br />
<br />
=== Set default username ===<br />
<br />
SLiM can be configured to automatically set a desired username, which will therefore already be completed. The password field will also already be focused by default. Change the following line in {{ic|/etc/slim.conf}}:<br />
<br />
# default_user simone<br />
<br />
Uncomment this line, and change "simone" to the username of choice:<br />
<br />
default_user ''your username''<br />
<br />
=== Enable Autologin ===<br />
<br />
{{Note|It will be necessary to have first set SLiM to use a single desktop environment, as well as a default username.}}<br />
<br />
{{Warning|Do '''not''' set this for the '''root''' account.}}<br />
<br />
{{Warning|1=If auto login is enabled, the GNOME keyring will not be unlocked automatically on login. This will cause dependent applications, such as Chrome/Chromium and NetworkManager, to misbehave (see https://bbs.archlinux.org/viewtopic.php?id&#61;167579).}}<br />
<br />
Edit {{ic|/etc/slim.conf}} to uncomment the {{ic|auto_login}} command and replace {{ic|no}} with {{ic|yes}}:<br />
<br />
auto_login yes<br />
<br />
=== Theming ===<br />
<br />
[[pacman|Install]] the {{Pkg|slim-themes}} package. The {{Pkg|archlinux-themes-slim}} packages contains several different themes ([http://imageshack.us/photo/my-images/27/slimthemes.png/ slimthemes.png]). Look in the directory of {{ic|/usr/share/slim/themes}} to see the themes available. Enter the theme name on the {{ic|current_theme}} line in {{ic|/etc/slim.conf}}:<br />
<br />
#current_theme default<br />
current_theme archlinux-simplyblack<br />
<br />
To preview a theme run while an instance of the Xorg server is running by:<br />
<br />
$ slim -p /usr/share/slim/themes/<theme name><br />
<br />
To close, type "exit" in the Login line and press Enter.<br />
<br />
Additional theme packages can be found in the [[AUR]].<br />
<br />
==== Dual screen setup ====<br />
<br />
You can customize the slim theme in {{ic|/usr/share/slim/themes/<your-theme>/slim.theme}} to turn these percents values. The box itself is 450 pixels by 250 pixels:<br />
<br />
input_panel_x 50%<br />
input_panel_y 50%<br />
<br />
into pixels values:<br />
<br />
# These settings set the "archlinux-simplyblack" panel in the center of a 1440x900 screen<br />
input_panel_x 495<br />
input_panel_y 325<br />
<br />
# These settings set the "archlinux-retro" panel in the center of a 1680x1050 screen<br />
input_panel_x 615<br />
input_panel_y 400<br />
<br />
If your theme has a background picture you should use the background_style setting ('stretch', 'tile', 'center' or 'color') to get it correctly displayed. Have a look at the [https://web.archive.org/web/20140414001555/http://slim.berlios.de/themes_howto.php very simple and clear official documentation about slim themes] for further details.<br />
<br />
== Other options ==<br />
<br />
=== Changing the cursor ===<br />
<br />
After installing, edit {{ic|/etc/slim.conf}} and uncomment the line:<br />
<br />
cursor left_ptr<br />
<br />
This will give you a normal arrow instead. This setting is forwarded to {{ic|xsetroot -cursor_name}}. You can look up the possible cursor names [http://cvsweb.xfree86.org/cvsweb/*checkout*/xc/lib/X11/cursorfont.h?rev=HEAD&content-type=text/plain here] or in {{ic|/usr/share/icons/<your-cursor-theme>/cursors/}}.<br />
<br />
To change the cursor theme being used at the login screen, see [[Cursor_Themes#Using_an_index.theme_file_.28recommended.29]].<br />
<br />
=== Match SLiM and Desktop Wallpaper ===<br />
<br />
To share a wallpaper between SLiM and your desktop, rename the used theme background, then create a link from your desktop wallpaper file to the default SLiM theme:<br />
<br />
# mv /usr/share/slim/themes/default/background.jpg{,.bck}<br />
# ln -s /path/to/mywallpaper.jpg /usr/share/slim/themes/default/background.jpg<br />
<br />
=== Shutdown, reboot, suspend, exit, launch terminal from SLiM ===<br />
<br />
You may shutdown, reboot, suspend, exit or even launch a terminal from the SLiM login screen. To do so, use the values in the username field, and the root password in the password field:<br />
<br />
* To launch a terminal, enter '''console''' as the username (defaults to xterm which must be installed separately... edit {{ic|/etc/slim.conf}} to change terminal preference)<br />
* For shutdown, enter '''halt''' as the username<br />
* For reboot, enter '''reboot''' as the username<br />
* To exit to bash, enter '''exit''' as the username<br />
* For suspend, enter '''suspend''' as the username. Suspend is disabled by default, edit {{ic|/etc/slim.conf}} as root to uncomment the {{ic|suspend_cmd}} line and, if necessary, modify the suspend command itself (by e.g. changing {{ic|/usr/sbin/suspend}} to {{ic|sudo /usr/sbin/pm-suspend}}).<br />
<br />
=== Power-off error with Splashy ===<br />
<br />
If you use Splashy and SLiM, sometimes you can't power-off or reboot from menu in GNOME, Xfce, LXDE or others. Check your {{ic|/etc/slim.conf}} and {{ic|/etc/splash.conf}}; set the {{ic|1=DEFAULT_TTY=7}} same as {{ic|xserver_arguments vt07}}.<br />
<br />
=== Power-off tray icon fails ===<br />
<br />
If your power off tray icon fails, it could be due to not having root privileges. To start a tray icon with root privileges, be sure to have SLiM start the program. Edit {{ic|/etc/slim.conf}} as follows:<br />
<br />
sessionstart_cmd /path/to/tray/icon/program &<br />
<br />
=== Login information with SLiM ===<br />
<br />
By default, SLiM fails to log logins to utmp and wtmp which causes who, last, etc. to misreport login information. To fix this edit your {{ic|slim.conf}} as follows:<br />
<br />
sessionstart_cmd /usr/bin/sessreg -a -l $DISPLAY %user<br />
sessionstop_cmd /usr/bin/sessreg -d -l $DISPLAY %user<br />
<br />
=== Custom SLiM Login Commands ===<br />
<br />
You can also use the sessionstart_cmd/sessionstop_cmd in {{ic|/etc/slim.conf}} to log specific infomation, such as the session, user, or theme used by slim:<br />
<br />
sessionstop_cmd /usr/bin/logger -i -t ASKAPACHE "(sessionstop_cmd: u:%user s:%session t:%theme)"<br />
sessionstart_cmd /usr/bin/logger -i -t ASKAPACHE "(sessionstart_cmd: u:%user s:%session t:%theme)"<br />
<br />
Or if you want to play a song when slim loads (and you have the beep program installed)<br />
<br />
sessionstart_cmd /usr/bin/beep -f 659 -l 460 -n -f 784 -l 340 -n -f 659 -l 230 -n -f 659 -l 110<br />
<br />
=== SLiM and Gnome Keyring ===<br />
<br />
{{Note|slim 1.3.5-1 ships with {{ic|/etc/pam.d/slim}} preconfigured to unlock keyring upon login. Users no longer need to modify the file.}}<br />
{{Warning|1=If auto login is enabled, the GNOME keyring will not be unlocked automatically on login. This will cause dependent applications, such as Chrome/Chromium and NetworkManager, to misbehave (see https://bbs.archlinux.org/viewtopic.php?id=167579).}}<br />
<br />
See [[GNOME Keyring#Use Without GNOME, and without a display manager]] to use GNOME Keyring in a custom session.<br />
<br />
=== Setting DPI with SLiM ===<br />
<br />
The Xorg server generally picks up the DPI but if it doesn't you can specify it to SLiM. If you set the DPI with the argument -dpi 96 in {{ic|/etc/X11/xinit/xserverrc}} it will not work with SLiM. To fix this change your {{ic|slim.conf}} from:<br />
<br />
xserver_arguments -nolisten tcp vt07 <br />
<br />
to<br />
<br />
xserver_arguments -nolisten tcp vt07 -dpi 96<br />
<br />
=== Use a random theme ===<br />
<br />
Use the {{ic|current_theme}} variable as a comma separated list to specify a set from which to choose. Selection is random.<br />
<br />
=== Move the whole session to another VT ===<br />
<br />
If tty terminals 3-6 are not used and commented out (You may use screen and therefore only need one terminal), change {{ic|/etc/slim.conf}} to move the X server:<br />
<br />
xserver_arguments -nolisten tcp vt07<br />
<br />
Simply change the vt07 to for example vt03 as no agetty is started there.<br />
<br />
=== Automatically mount your encrypted /home on login ===<br />
<br />
See [[Pam_mount#Slim|pam_mount]].<br />
<br />
=== Change Keyboard Layout ===<br />
<br />
Edit {{ic|/etc/X11/xorg.conf.d/10-evdev.conf}}, find the following section, add the two bolded lines, and replace ''dvorak'' with your preferred keymap:<br />
<br />
Section "InputClass"<br />
Identifier "evdev keyboard catchall"<br />
MatchIsKeyboard "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Driver "evdev"<br />
<br />
'''# Keyboard layouts'''<br />
'''Option "XkbLayout" "''dvorak''"'''<br />
EndSection<br />
<br />
== All Slim Options ==<br />
<br />
Here is a list of all the slim configuration options and their default values.<br />
<br />
{{Note|{{ic|welcome_msg}} allows 2 variables '''%host''' and '''%domain'''<br />
<br />
{{ic|sessionstart_cmd}} allows '''%user''' (executed right before login_cmd) and it is also allowed in {{ic|sessionstop_cmd}}<br />
<br />
{{ic|login_cmd}} allows '''%session''' and '''%theme'''}}<br />
<br />
{| class="wikitable collapsible collapsable collapsed"<br />
|-<br />
! Option Name || Default Value<br />
|-<br />
| default_path ||{{ic|/bin:/usr/bin:/usr/local/bin}}<br />
|-<br />
| default_xserver ||{{ic|/usr/bin/X}}<br />
|-<br />
| xserver_arguments ||{{ic|vt07 -auth /var/run/slim.auth}}<br />
|-<br />
| numlock ||<br />
|-<br />
| daemon || {{ic|yes}}<br />
|-<br />
| xauth_path ||{{ic|/usr/bin/xauth}}<br />
|-<br />
| login_cmd ||{{ic|exec /bin/bash -login ~/.xinitrc %session}}<br />
|-<br />
| halt_cmd ||{{ic|/sbin/shutdown -h now}}<br />
|-<br />
| reboot_cmd ||{{ic|/sbin/shutdown -r now}}<br />
|-<br />
| suspend_cmd ||<br />
|-<br />
| sessionstart_cmd ||<br />
|-<br />
| sessionstop_cmd ||<br />
|-<br />
| console_cmd ||{{ic|/usr/bin/xterm -C -fg white -bg black +sb -g %dx%d+%d+%d -fn %dx%d -T }}<br />
|-<br />
| screenshot_cmd ||{{ic|import -window root /slim.png}}<br />
|-<br />
| welcome_msg ||{{ic|Welcome to %host}}<br />
|-<br />
| session_msg ||{{ic|Session:}}<br />
|-<br />
| default_user ||<br />
|-<br />
| focus_password ||{{ic|no}}<br />
|-<br />
| auto_login ||{{ic|no}}<br />
|-<br />
| current_theme ||{{ic|default}}<br />
|-<br />
| lockfile ||{{ic|/var/run/slim.lock}}<br />
|-<br />
| logfile ||{{ic|/var/log/slim.log}}<br />
|-<br />
| authfile ||{{ic|/var/run/slim.auth}}<br />
|-<br />
| shutdown_msg ||{{ic|The system is halting...}}<br />
|-<br />
| reboot_msg ||{{ic|The system is rebooting...}}<br />
|-<br />
| sessiondir ||{{ic| /usr/share/xsessions/}}<br />
|-<br />
| hidecursor ||{{ic|false}}<br />
|-<br />
| input_panel_x ||{{ic|50%}}<br />
|-<br />
| input_panel_y ||{{ic|40%}}<br />
|-<br />
| input_name_x ||{{ic|200}}<br />
|-<br />
| input_name_y ||{{ic|154}}<br />
|-<br />
| input_pass_x ||{{ic|-1}}<br />
|-<br />
| input_pass_y ||{{ic|-1}}<br />
|-<br />
| input_font ||{{ic|1=Verdana:size=11}}<br />
|-<br />
| input_color ||{{ic|#000000}}<br />
|-<br />
| input_cursor_height ||{{ic|20}}<br />
|-<br />
| input_maxlength_name ||{{ic|20}}<br />
|-<br />
| input_maxlength_passwd ||{{ic|20}}<br />
|-<br />
| input_shadow_xoffset ||{{ic|0}}<br />
|-<br />
| input_shadow_yoffset ||{{ic|0}}<br />
|-<br />
| input_shadow_color ||{{ic|#FFFFFF}}<br />
|-<br />
| welcome_font ||{{ic|1=Verdana:size=14}}<br />
|-<br />
| welcome_color ||{{ic|#FFFFFF}}<br />
|-<br />
| welcome_x ||{{ic|-1}}<br />
|-<br />
| welcome_y ||{{ic|-1}}<br />
|-<br />
| welcome_shadow_xoffset ||{{ic|0}}<br />
|-<br />
| welcome_shadow_yoffset ||{{ic|0}}<br />
|-<br />
| welcome_shadow_color ||{{ic|#FFFFFF}}<br />
|-<br />
| intro_msg ||<br />
|-<br />
| intro_font ||{{ic|1=Verdana:size=14}}<br />
|-<br />
| intro_color ||{{ic|#FFFFFF}}<br />
|-<br />
| intro_x ||{{ic|-1}}<br />
|-<br />
| intro_y ||{{ic|-1}}<br />
|-<br />
| background_style ||{{ic|stretch}}<br />
|-<br />
| background_color ||{{ic|#CCCCCC}}<br />
|-<br />
| username_font ||{{ic|1=Verdana:size=12}}<br />
|-<br />
| username_color ||{{ic|#FFFFFF}}<br />
|-<br />
| username_x ||{{ic|-1}}<br />
|-<br />
| username_y ||{{ic|-1}}<br />
|-<br />
| username_msg ||{{ic|Please enter your username}}<br />
|-<br />
| username_shadow_xoffset ||{{ic|0}}<br />
|-<br />
| username_shadow_yoffset ||{{ic|0}}<br />
|-<br />
| username_shadow_color ||{{ic|#FFFFFF}}<br />
|-<br />
| password_x ||{{ic|-1}}<br />
|-<br />
| password_y ||{{ic|-1}}<br />
|-<br />
| password_msg ||{{ic|Please enter your password}}<br />
|-<br />
| msg_color ||{{ic|#FFFFFF}}<br />
|-<br />
| msg_font ||{{ic|1=Verdana:size=16:bold}}<br />
|-<br />
| msg_x ||{{ic|40}}<br />
|-<br />
| msg_y ||{{ic|40}}<br />
|-<br />
| msg_shadow_xoffset ||{{ic|0}}<br />
|-<br />
| msg_shadow_yoffset ||{{ic|0}}<br />
|-<br />
| msg_shadow_color ||{{ic|#FFFFFF}}<br />
|-<br />
| session_color ||{{ic|#FFFFFF}}<br />
|-<br />
| session_font ||{{ic|1=Verdana:size=16:bold}}<br />
|-<br />
| session_x ||{{ic|50%}}<br />
|-<br />
| session_y ||{{ic|90%}}<br />
|-<br />
| session_shadow_xoffset ||{{ic|0}}<br />
|-<br />
| session_shadow_yoffset ||{{ic|0}}<br />
|-<br />
| session_shadow_color ||{{ic|#FFFFFF}}<br />
|}<br />
<br />
== See also ==<br />
* [http://sourceforge.net/projects/slim.berlios/ SLiM on SourceForge]<br />
* [https://github.com/data-modul/slim SLiM on GitHub]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Hard_Drive_Active_Protection_System&diff=59714Hard Drive Active Protection System2009-01-31T23:31:42Z<p>ColdPie: Removed the hash marks in the config file sections. They could mislead someone to add them to the file, making the lines commented out.</p>
<hr />
<div>This page describes how to install HDAPS on your Arch Linux installation. HDAPS stands for "Hard Drive Active Protection System." Its purpose is to protect your hard drive from sudden shocks (such as dropping or banging your laptop on a desk). It does this by parking the disk heads, so that shocks don't cause them to crash into the drive's platters. Hopefully, this will prevent catastrophic failure.<br />
<br />
As of Linux 2.6.28, the kernel has the ability to park disk heads on demand. Previously, this had to be patched into the kernel. Thanks to the kernel devs' hard work, we no longer have to rebuild our kernel to use this feature. Obviously, this means you need to be running 2.6.28 to follow this guide.<br />
<br />
==Shock Detection==<br />
Your hardware needs to support some kind of shock detection. This is usually in the form of an accelerometer built into your laptop's motherboard. If you have the hardware, you also need a way to communicate what the hardware is detecting to your operating system. This section describes drivers to communicate the accelerometer's state to the OS so it can detect and protect against shocks.<br />
<br />
===tp_smapi===<br />
[[tp_smapi]] is a set of drivers for ThinkPad laptops. It is highly recommended if you have a ThinkPad, even if you don't plan to use HDAPS. Among a plethora of other useful things, tp_smapi represents the accelerometer output as joystick devices <code>/dev/js#</code> (Note! This could interfere with other joystick devices on your system). <br />
<br />
Install [http://aur.archlinux.org/packages.php?ID=3985 tp_smapi] from AUR. After installing, add <code>tp_smapi</code> to your <code>MODULES</code> array. After a reboot, this will activate most of the drivers, represented through the <code>/sys/devices/platform/smapi</code> filesystem.<br />
<br />
The kernel provides its own HDAPS drivers. For this reason, the HDAPS part of tp_smapi is built separately. Attempting to add <code>hdaps</code> to your <code>MODULES</code> array will result in the default drivers being loaded. This is not what we want, as we have our special ThinkPad HDAPS drivers. Instead, modify your /etc/rc.local and add the following line:<br />
insmod /lib/modules/2.6.28-ARCH/extra/hdaps.ko<br />
<br />
This will load the ThinkPad HDAPS module at the end of the initialization sequence.<br />
<br />
==Shock Protection==<br />
Now that your hardware is reporting its shock detection to the OS, we need to do something with this data. This section describes software utilities to transform the sensor output into shock protection.<br />
<br />
===hdapsd===<br />
hdapsd monitors the output of the HDAPS joystick devices to determine if a shock is about to occur, then tells the kernel to park the disk heads.<br />
<br />
Install [http://aur.archlinux.org/packages.php?ID=5401 hdapsd] from AUR. Be sure to review <code>/etc/conf.d/hdapsd</code> to ensure that it's protecting the correct hard drive.<br />
<br />
Because we have to load the hdaps module in <code>rc.local</code>, which executes after the DAEMONS array is loaded, we have to put hdapsd in rc.local instead of in DAEMONS like usual. Modify <code>/etc/rc.local</code> again, putting this line after the insmod added above:<br />
/etc/rc.d/hdapsd start<br />
After a reboot, your computer will now monitor the joystick devices and park your disk heads to protect it against shocks.<br />
<br />
Reboot your computer at this point. After init, if you jiggle your laptop, you should be able to hear the hard drive park. Don't do this too much <code>:)</code><br />
<br />
==GUI Utilities==<br />
Utilities exist to monitor hdapsd's status so you know what's going on while you're using your laptop. These are entirely optional, but very handy.<br />
<br />
===gnome-hdaps-applet===<br />
This is a GNOME panel applet (Note: XFCE can use GNOME panel applets) that represents the current status of your hard drive. If the disk heads are parked by hdapsd, this applet will reflect that. Unfortunately, the AUR project for gnome-hdaps-applet is very out of date and does not work any longer. This should be fixed, but for now, here's how to do it manually. Note that pacman '''will not''' manage these files. If you update this applet later, you'll have to manually remove and replace these files.<br />
<br />
First, grab the latest gnome-hdaps-applet sources from the [http://www.zen24593.zen.co.uk/hdaps/ this HDAPS mirror]. As of this writing, this is version <code>20081204</code>. Inflate these files, and follow the instructions in <code>INSTALL</code>. It's very straight-forward. When you're done, keep the <code>INSTALL</code> file around for future reference if you have to update or uninstall the applet later. Again, remember that pacman will not manage these files for you in any way.<br />
<br />
===khdapsmonitor===<br />
A KDE version exists as well. [http://aur.archlinux.org/packages.php?ID=12679 khdapsmonitor] in AUR. (Someone who uses KDE, please research and update this section.)<br />
<br />
===hdaps-gl===<br />
Simple OpenGL application showing the 3D animation of your Thinkpad. Similar to the apllication Lenovo distibutes with Windows. [http://aur.archlinux.org/packages.php?ID=23485 hdaps-gl] is available in AUR.<br />
<br />
==See Also==<br />
*[http://www.thinkwiki.org/wiki/How_to_protect_the_harddisk_through_APS How to protect the harddisk through APS at ThinkWiki]<br />
*[http://www.thinkwiki.org/wiki/HDAPS HDAPS at ThinkWiki]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Hard_Drive_Active_Protection_System&diff=58400Hard Drive Active Protection System2009-01-19T23:18:48Z<p>ColdPie: </p>
<hr />
<div>This page describes how to install HDAPS on your Arch Linux installation. HDAPS stands for "Hard Drive Active Protection System." Its purpose is to protect your hard drive from sudden shocks (such as dropping or banging your laptop on a desk). It does this by parking the disk heads, so that shocks don't cause them to crash into the drive's platters. Hopefully, this will prevent catastrophic failure.<br />
<br />
As of Linux 2.6.28, the kernel has the ability to park disk heads on demand. Previously, this had to be patched into the kernel. Thanks to the kernel devs' hard work, we no longer have to rebuild our kernel to use this feature. Obviously, this means you need to be running 2.6.28 to follow this guide.<br />
<br />
==Shock Detection==<br />
Your hardware needs to support some kind of shock detection. This is usually in the form of an accelerometer built into your laptop's motherboard. If you have the hardware, you also need a way to communicate what the hardware is detecting to your operating system. This section describes drivers to communicate the accelerometer's state to the OS so it can detect and protect against shocks.<br />
<br />
===tp_smapi===<br />
[[tp_smapi]] is a set of drivers for ThinkPad laptops. It is highly recommended if you have a ThinkPad, even if you don't plan to use HDAPS. Among a plethora of other useful things, tp_smapi represents the accelerometer output as joystick devices <code>/dev/js#</code> (Note! This could interfere with other joystick devices on your system). <br />
<br />
Install [http://aur.archlinux.org/packages.php?ID=3985 tp_smapi] from AUR. After installing, add <code>tp_smapi</code> to your <code>MODULES</code> array. After a reboot, this will activate most of the drivers, represented through the <code>/sys/devices/platform/smapi</code> filesystem.<br />
<br />
The kernel provides its own HDAPS drivers. For this reason, the HDAPS part of tp_smapi is built separately. Attempting to add <code>hdaps</code> to your <code>MODULES</code> array will result in the default drivers being loaded. This is not what we want, as we have our special ThinkPad HDAPS drivers. Instead, modify your /etc/rc.local and add the following line:<br />
<br />
insmod /lib/modules/2.6.28-ARCH/extra/hdaps.ko<br />
<br />
This will load the ThinkPad HDAPS module at the end of the initialization sequence.<br />
<br />
==Shock Protection==<br />
Now that your hardware is reporting its shock detection to the OS, we need to do something with this data. This section describes software utilities to transform the sensor output into shock protection.<br />
<br />
===hdapsd===<br />
hdapsd monitors the output of the HDAPS joystick devices to determine if a shock is about to occur, then tells the kernel to park the disk heads.<br />
<br />
Install [http://aur.archlinux.org/packages.php?ID=5401 hdapsd] from AUR. Be sure to review <code>/etc/conf.d/hdapsd</code> to ensure that it's protecting the correct hard drive.<br />
<br />
Because we have to load the hdaps module in <code>rc.local</code>, which executes after the DAEMONS array is loaded, we have to put hdapsd in rc.local instead of in DAEMONS like usual. Modify <code>/etc/rc.local</code> again, putting this line after the insmod added above:<br />
/etc/rc.d/hdaps start<br />
After a reboot, your computer will now monitor the joystick devices and park your disk heads to protect it against shocks.<br />
<br />
Reboot your computer at this point. After init, if you jiggle your laptop, you should be able to hear the hard drive park. Don't do this too much <code>:)</code> <br />
<br />
==GUI Utilities==<br />
Utilities exist to monitor hdapsd's status so you know what's going on while you're using your laptop. These are entirely optional, but very handy.<br />
<br />
===gnome-hdaps-applet===<br />
This is a GNOME panel applet (Note: XFCE can use GNOME panel applets) that represents the current status of your hard drive. If the disk heads are parked by hdapsd, this applet will reflect that. Unfortunately, the AUR project for gnome-hdaps-applet is very out of date and does not work any longer. This should be fixed, but for now, here's how to do it manually. Note that pacman '''will not''' manage these files. If you update this applet later, you'll have to manually remove and replace these files.<br />
<br />
First, grab the latest gnome-hdaps-applet sources from the [http://www.zen24593.zen.co.uk/hdaps/ this HDAPS mirror]. As of this writing, this is version <code>20081204</code>. Inflate these files, and follow the instructions in <code>INSTALL</code>. It's very straight-forward. When you're done, keep the <code>INSTALL</code> file around for future reference if you have to update or uninstall the applet later. Again, remember that pacman will not manage these files for you in any way.<br />
<br />
===khdapsmonitor===<br />
A KDE version exists as well. [http://aur.archlinux.org/packages.php?ID=12679 khdapsmonitor] in AUR. (Someone who uses KDE, please research and update this section.)<br />
<br />
==See Also==<br />
[http://www.thinkwiki.org/wiki/How_to_protect_the_harddisk_through_APS How to protect the harddisk through APS at ThinkWiki]<br />
<br />
[http://www.thinkwiki.org/wiki/HDAPS HDAPS at ThinkWiki]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Bitlbee&diff=58399Bitlbee2009-01-19T23:09:36Z<p>ColdPie: </p>
<hr />
<div>[[Category:Internet and Email (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Bitlbee}}<br />
{{i18n_entry|Türkçe|Bitlbee (Türkçe)}}<br />
{{i18n_links_end}}<br />
<br />
= About =<br />
<br />
[http://www.bitlbee.org/main.php/news.r.html Bitlbee] is a "console-based IRC to IM chatting gateway, including ICQ/MSN/Jabber". Basically, it allows the user to interact with popular chat networks (ICQ, MSN, Jabber, AIM, YIM) within their IRC client.<br />
<br />
The users' buddies appear as normal IRC users in a channel and conversations use the private message facility of IRC.<br />
<br />
<br />
= Setup =<br />
<br />
First, download and install the package using pacman:<br />
<br />
# pacman -S bitlbee<br />
<br />
Bitlbee can now run as a daemon of its own! Open up /etc/bitlbee/bitlbee.conf to browse through the settings. Edit the "RunMode" line to "ForkDaemon", then run<br />
/etc/rc.d/bitlbee start<br />
to start the Bitlbee server. Of course, add bitlbee to your DAEMONS array in /etc/rc.conf to start the server on boot. Note that just starting the server does not log you in to any of your messenger accounts! You must join a channel and issue commands.<br />
<br />
= Configuration =<br />
You are now able to connect to this in an IRC client. To connect, just connect to localhost using your favorite IRC client.<br />
<br />
Hopefully this will connect and you should immediately join a channel called '&bitlbee'. When you join this channel it will tell to type 'Help' if you're new... type 'Help' ;)<br />
<br />
Read through the help offered by Bitlbee to get started. There are some great guides online too:<br />
<br />
http://quark.humbug.org.au/publications/internet/bitlbee.pdf<br />
<br />
http://princessleia.com/bitlbee.php<br />
<br />
= How to connect to Jabber using your Gmail account =<br />
In your control channel do the following:<br />
account add jabber username@gmail.com mypasswd<br />
<br />
After root responds with "Account successfully added" you can check your accounts with "account list".<br />
<br />
<@user> account list <br />
<@root> 0. JABBER, username@gmail.com (connected) <br />
<@root> End of account list<br />
<br />
After you have added the account, type "account on 0" and it should log in:<br />
<br />
<@user> account on 0 <br />
<@root> JABBER(username@gmail.com) - Logging in: Connecting <br />
<@root> JABBER(username@gmail.com) - Logging in: Connected <br />
<@root> JABBER(username@gmail.com) - Logging in: Requesting Authentication Method<br />
<@root> JABBER(username@gmail.com) - Logging in: Authenticating <br />
<@root> JABBER(username@gmail.com) - Logged in<br />
<br />
If you get errors like the following:<br />
<br />
<@user> account on 0 <br />
<@root> JABBER(username@gmail.com) - Logging in: Connecting<br />
<@root> JABBER(username@gmail.com) - Logging in: Connected<br />
<@root> JABBER(username@gmail.com) - Logging in: Requesting Authentication Method<br />
<@root> JABBER(username@gmail.com) - Logging in: Authenticating<br />
<@root> JABBER(username@gmail.com) - Login error: Error 403: Unknown error<br />
<@root> JABBER(username@gmail.com) - Signing off...<br />
<br />
Switching the domain from "gmail.com" to "googlemail.com" may help.<br />
This seems to be the case for some European countries, especially Germany where Google doesn't own the trademark for the name ''Gmail'' [http://www.theregister.co.uk/2007/01/31/google_looses_trademark_battle/].<br />
<br />
The easiest way to change your account settings is to simply delete the account you created and add it again.<br />
account del 0<br />
account add jabber username@googlemail.com mypasswd<br />
<br />
If you are still unable to connect, try switching the port to 5222. For some reason some people must connect on 5223 while others have to connect on 5222. There appears to be no way to know which one to use other than trial and error.<br />
<br />
= See Also =<br />
[[Screen Irssi Bitlbee]]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Laptop&diff=58398Laptop2009-01-19T23:08:01Z<p>ColdPie: </p>
<hr />
<div>[[Category:HOWTOs (English)]]<br />
[[Category:Laptops (English)]]<br />
<br />
= Setting Up For Laptops =<br />
This page should contain links to pages needed for configuring a laptop for the best experience. Setting up a laptop is in many was the same as setting up a desktop. However, there are a few key differences. When setting up a laptop with Arch Linux, the following points should be taken into consideration:<br />
<br />
* Power consumption (how do I make the battery last the longest per charge?). Which leads to power management:<br />
* Hard drive spindown. After how many minutes of inactivity should the hard drive be spun down?<br />
* Screen shut off. After how many minutes of inactivity should the screen be shut off? (Not just blanked with a screensaver but completely shut off).<br />
* CPU frequency scaling. How should the CPU's frequency change depending on load to minimize power usage?<br />
* Suspend and hibernate. How do I get suspend and hibernate to work with my laptop?<br />
* Screen brightness. How do I manage screen brightness in Linux?<br />
<br />
* Network and wireless. How do I get my wireless working?<br />
* Media buttons. How do I configure the function of those buttons on my laptop?<br />
* Touchpad. How do I configure the sensativity, acceleration, button function and scroll borders for my Synaptics or Alps touchpad?<br />
<br />
All of these points are important to take into consideration when getting a laptop set up the way you like. Fortunately, Arch Linux provides all the tools and programs necessary to take complete control of your laptop. These programs and utilities are highlighted below, with appropriate tips tutorials.<br />
<br />
<br />
Note: the following links may be useful:<br />
<br />
* [http://www.linux-on-laptops.com/ http://www.linux-on-laptops.com/]<br />
* [http://www.linlap.com/ http://www.linlap.com/]<br />
<br />
= Power Management =<br />
Power management is very important for anyone who wishes to make good use of their battery capacity. The following tools and programs help to increase battery life and keep your laptop cool and quiet.<br />
<br />
== Cpufrequtils ==<br />
<br />
[[Cpufrequtils]] provides CPU Frequency Scaling, a technology used primarily by notebooks which enables the OS to scale the CPU speed up or down, depending on the current system load and/or power scheme. For quick and easy installation and setup, please view the [[CPU Frequency Scaling]] article.<br />
<br />
== Pm-utils ==<br />
[[Pm-utils]] provides a suspend and powerstate setting framework. Pm-utils should be used with cpufrequtils to provide a complete power management solution.<br />
<br />
== Networkmanager ==<br />
[[Networkmanager]] provides automatic network detection and configuration for the system. Another clean and fast network manager is [[wicd]]. Wicd should be used when one does not want to install too many gnome dependencies or wants simplicity of setup and ease of use.<br />
<br />
Note: [[Networkmanager]] is being phased out in favor of [[network_profiles]]<br />
<br />
== Lapsus ==<br />
[[Asus_G1#The_Lapsus_daemon_.26_KDE_applet|Lapsus]] is a set of programs providing easy access to many features of various laptops. It currently supports most features provided by asus-laptop kernel module from ACPI4Asus project, such as additional LEDs, hotkeys, backlight control etc. It also has support for some IBM laptops features provided by IBM ThinkPad ACPI Extras Driver and NVRAM device.<br />
<br />
<br />
== Install powertop ==<br />
This handy util from Intel will tell you what hardware/processes are using the most power on your system, and provides instructions on how to stop/remove power-wasting services. Works great for mobile Intel CPUs; provides the current CPU state and suggestions for power saving. Also works on AMD systems, but does not provide as much information about the CPU state. Install with:<br />
<br />
# pacman -S powertop<br />
<br />
== Laptop mode tools ==<br />
Install laptop-mode-tools with:<br />
<br />
# pacman -S laptop-mode-tools<br />
<br />
* The configuration file can be found in /etc/laptop-mode/laptop-mode.conf.<br />
* Be sure to add ''laptop-mode'' to the DAEMONS line in /etc/rc.conf<br />
<br />
See [http://bbs.archlinux.org/viewtopic.php?id=39258 this thread] for more information.<br />
<br />
== Suggestions for saving power ==<br />
=== Disk-related tweaks ===<br />
Disable file access time: every time you access (read) a file the filesystem writes an access time to the file metadata. You can disable this on individual files by using the chattr command, or you can enable it on an entire disk by setting the ''noatime'' option in your fstab, as follows:<br />
<br />
/dev/sda1 / ext3 defaults,noatime 1 2<br />
<br />
[http://www.faqs.org/docs/securing/chap6sec73.html Source]<br />
<br />
<br />
To allow the CD/DVD rom to spin down after a while, run the following: <br />
<br />
/usr/bin/hal-disable-polling --device /dev/scd0<br />
<br />
=== Other tweaks ===<br />
These are some generic suggestions that will work with most laptops.<br />
<br />
Add the following to ''/etc/modprobe.d/options'':<br />
<br />
options usbcore autosuspend=1<br />
<br />
<br />
Add the following to ''/etc/sysctl.conf''<br />
<br />
vm.dirty_writeback_centisecs=1500<br />
vm.laptop_mode=5<br />
<br />
<br />
Add the following to ''/etc/rc.local'' (and make sure it gets executed at boot time)<br />
<br />
/usr/sbin/iwpriv eth1 set_power 5<br />
<br />
Source: [http://www.nervous.it/2007/11/linux-dell-xps-m1330/ here]<br />
<br />
=== Hard drive spin down problem ===<br />
Documented [https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 here]<br />
<br />
To prevent your laptop hard drive from spinning down too often (result of too aggressive APM defaults) do the following:<br />
<br />
Add the following to ''/etc/rc.local''<br />
<br />
hdparm -B 255 /dev/sdX ''where X is your hard drive device''<br />
<br />
<br />
<br />
Add the following to ''/etc/pm/sleep.d/50-hdparm_pm''<br />
<br />
#!/bin/sh<br />
<br />
if [ -n "$1" ] && ([ "$1" = "resume" ] || [ "$1" = "thaw" ]); then<br />
hdparm -B 255 /dev/your-hard-drive > /dev/null<br />
fi<br />
<br />
and run "chmod +x /etc/pm/sleep.d/50-hdparm_pm" to make sure it resets after suspend.<br />
<br />
Now APM should be turned off for your hard drive.<br />
<br />
= Touchpad =<br />
To get your touchpad working properly, see the [[Touchpad Synaptics]] page.<br />
<br />
= Special Buttons =<br />
To configure any special keys or buttons on your laptop, please refer to the following article: [http://www.linux.com/feature/118179 Customize your laptop keyboard with X and KDE]. Note that KDE is not required.<br />
<br />
= HDAPS =<br />
To protect your hard drive from shocks, consider installing some form of [[HDAPS|Hard Disk Active Protection System]].</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Hard_Drive_Active_Protection_System&diff=58397Hard Drive Active Protection System2009-01-19T23:01:01Z<p>ColdPie: </p>
<hr />
<div>This page describes how to install HDAPS on your Arch Linux installation. HDAPS stands for "Hard Drive Active Protection System." Its purpose is to protect your hard drive from sudden shocks (such as dropping or banging your laptop on a desk). It does this by parking the disk heads, so that shocks don't cause them to crash into the drive's platters. Hopefully, this will prevent catastrophic failure.<br />
<br />
As of Linux 2.6.28, the kernel has the ability to park disk heads on demand. Previously, this had to be patched into the kernel. Thanks to the kernel devs' hard work, we no longer have to rebuild our kernel to use this feature. Obviously, this means you need to be running 2.6.28 to follow this guide.<br />
<br />
==Shock Detection==<br />
Your hardware needs to support some kind of shock detection. This is usually in the form of an accelerometer built into your laptop's motherboard. If you have the hardware, you also need a way to communicate what the hardware is detecting to your operating system. This section describes drivers to communicate the accelerometer's state to the OS so it can detect and protect against shocks.<br />
<br />
===tp_smapi===<br />
[[tp_smapi]] is a set of drivers for ThinkPad laptops. It is highly recommended if you have a ThinkPad, even if you don't plan to use HDAPS. Among a plethora of other useful things, tp_smapi represents the accelerometer output as joystick devices <code>/dev/js#</code> (Note! This could interfere with other joystick devices on your system). <br />
<br />
Install [http://aur.archlinux.org/packages.php?ID=3985 tp_smapi] from AUR. After installing, add <code>tp_smapi</code> to your <code>MODULES</code> array. After a reboot, this will activate most of the drivers, represented through the <code>/sys/devices/platform/smapi</code> filesystem.<br />
<br />
The kernel provides its own HDAPS drivers. For this reason, the HDAPS part of tp_smapi is built separately. Attempting to add <code>hdaps</code> to your <code>MODULES</code> array will result in the default drivers being loaded. This is not what we want, as we have our special ThinkPad HDAPS drivers. Instead, modify your /etc/rc.local and add the following line:<br />
<br />
insmod /lib/modules/2.6.28-ARCH/extra/hdaps.ko<br />
<br />
This will load the ThinkPad HDAPS module at the end of the initialization sequence.<br />
<br />
==Shock Protection==<br />
Now that your hardware is reporting its shock detection to the OS, we need to do something with this data. This section describes software utilities to transform the sensor output into shock protection.<br />
<br />
===hdapsd===<br />
hdapsd monitors the output of the HDAPS joystick devices to determine if a shock is about to occur, then tells the kernel to park the disk heads.<br />
<br />
Install [http://aur.archlinux.org/packages.php?ID=5401 hdapsd] from AUR. After installing, add <code>hdapsd</code> to your <code>DAEMONS</code> array. Also be sure to review <code>/etc/conf.d/hdapsd</code> to ensure that it's protecting the correct hard drive. After a reboot, your computer will now monitor the joystick devices and park your disk heads to protect it against shocks.<br />
<br />
Reboot your computer at this point. After init, if you jiggle your laptop, you should be able to hear the hard drive park. Don't do this too much <code>:)</code> <br />
<br />
==GUI Utilities==<br />
Utilities exist to monitor hdapsd's status so you know what's going on while you're using your laptop. These are entirely optional, but very handy.<br />
<br />
===gnome-hdaps-applet===<br />
This is a GNOME panel applet (Note: XFCE can use GNOME panel applets) that represents the current status of your hard drive. If the disk heads are parked by hdapsd, this applet will reflect that. Unfortunately, the AUR project for gnome-hdaps-applet is very out of date and does not work any longer. This should be fixed, but for now, here's how to do it manually. Note that pacman '''will not''' manage these files. If you update this applet later, you'll have to manually remove and replace these files.<br />
<br />
First, grab the latest gnome-hdaps-applet sources from the [http://www.zen24593.zen.co.uk/hdaps/ this HDAPS mirror]. As of this writing, this is version <code>20081204</code>. Inflate these files, and follow the instructions in <code>INSTALL</code>. It's very straight-forward. When you're done, keep the <code>INSTALL</code> file around for future reference if you have to update or uninstall the applet later. Again, remember that pacman will not manage these files for you in any way.<br />
<br />
===khdapsmonitor===<br />
A KDE version exists as well. [http://aur.archlinux.org/packages.php?ID=12679 khdapsmonitor] in AUR. (Someone who uses KDE, please research and update this section.)<br />
<br />
==See Also==<br />
[http://www.thinkwiki.org/wiki/How_to_protect_the_harddisk_through_APS How to protect the harddisk through APS at ThinkWiki]<br />
<br />
[http://www.thinkwiki.org/wiki/HDAPS HDAPS at ThinkWiki]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Tp_smapi&diff=58396Tp smapi2009-01-19T22:54:20Z<p>ColdPie: </p>
<hr />
<div>tp_smapi is a set of kernel modules that retrieves information from and conveys commands to the hardware of ThinkPad laptops. This information is presented through the <code>/sys/devices/platform/smapi</code> filesystem. Much like the <code>/proc</code> filesystem, you can read and write information to these files to get information about and send commands to the hardware. tp_smapi is highly recommended if you're using a ThinkPad laptop.<br />
<br />
==Installation==<br />
Install [http://aur.archlinux.org/packages.php?ID=3985 tp_smapi] from AUR. After installing, add tp_smapi to your MODULES array. After a reboot, this will activate most of the drivers, represented through the <code>/sys/devices/platform/smapi</code> filesystem.<br />
<br />
==Features==<br />
Here are a couple of useful things you can do using tp_smapi. Please feel free to add your own.<br />
<br />
===Control Battery Charging===<br />
[http://www.thinkwiki.org/wiki/Maintenance#Battery_treatment It's bad for most laptop batteries to hold a full charge for long periods of time.] You should try to keep your battery in the 40-80% charged range, unless you need the battery life for extended periods of time. tp_smapi lets you control the start and stop charging threshold to do just that. Run these commands to set these to good values:<br />
echo 40 > /sys/devices/platform/smapi/BAT0/start_charge_thresh<br />
echo 80 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh<br />
This will cause the battery to begin charging when it falls below 40% charge and stop charging once it exceeds 80% charge. This will extend the lifetime of your battery.<br />
<br />
Note that when you remove and re-insert the battery, these thresholds may be reset to their default values. To work around this, create a script to set these values, and make this script run both at startup and when a battery is inserted. More specific instructions follow.<br />
<br />
Create a script <code>/usr/sbin/set_battery_thresholds</code>:<br />
#!/bin/bash<br />
# set the battery charging thresholds to extend battery lifespan<br />
echo 40 > /sys/devices/platform/smapi/BAT0/start_charge_thresh<br />
echo 80 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh<br />
Set it runnable:<br />
[root ~]# '''chmod 744 /usr/sbin/set_battery_threshold'''<br />
Make this script run at startup by editing <code>/etc/rc.local</code>:<br />
#... other rc.local stuff<br />
'''/usr/sbin/set_battery_thresholds'''<br />
Make it run when a battery is inserted. This requires that [[acpid]] is installed and running. Edit <code>/etc/acpi/handler.sh</code>:<br />
#... other ACPI stuff<br />
battery)<br />
case "$2" in<br />
BAT0)<br />
case "$4" in<br />
00000000)<br />
;;<br />
00000001)<br />
'''/usr/sbin/set_battery_thresholds'''<br />
;;<br />
#... more ACPI stuff<br />
<br />
===Protect the Hard Disk from Drops===<br />
tp_smapi includes a driver to read the accelerometer in your laptop to detect drops and other events that could cause damage to your hard drive. See the [[HDAPS]] page for more information on this useful feature.<br />
<br />
==See Also==<br />
[http://www.thinkwiki.org/wiki/Tp_smapi tp_smapi on ThinkWiki]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Tp_smapi&diff=58395Tp smapi2009-01-19T22:52:10Z<p>ColdPie: </p>
<hr />
<div>tp_smapi is a set of kernel modules that retrieves information from and conveys commands to the hardware of ThinkPad laptops. This information is presented through the <code>/sys/devices/platform/smapi</code> filesystem. Much like the <code>/proc</code> filesystem, you can read and write information to these files to get information about and send commands to the hardware. tp_smapi is highly recommended if you're using a ThinkPad laptop.<br />
<br />
==Installation==<br />
Install [http://aur.archlinux.org/packages.php?ID=3985 tp_smapi] from AUR. After installing, add tp_smapi to your MODULES array. After a reboot, this will activate most of the drivers, represented through the <code>/sys/devices/platform/smapi</code> filesystem.<br />
<br />
==Features==<br />
Here are a couple of useful things you can do using tp_smapi. Please feel free to add your own.<br />
<br />
===Control Battery Charging===<br />
It's bad for most laptop batteries to hold a full charge for long periods of time. You should try to keep your battery in the 40-80% charged range, unless you need the battery life for extended periods of time. tp_smapi lets you control the start and stop charging threshold to do just that. Run these commands to set these to good values:<br />
echo 40 > /sys/devices/platform/smapi/BAT0/start_charge_thresh<br />
echo 80 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh<br />
This will cause the battery to begin charging when it falls below 40% charge and stop charging once it exceeds 80% charge. This will extend the lifetime of your battery.<br />
<br />
Note that when you remove and re-insert the battery, these thresholds may be reset to their default values. To work around this, create a script to set these values, and make this script run both at startup and when a battery is inserted. More specific instructions follow.<br />
<br />
Create a script <code>/usr/sbin/set_battery_thresholds</code>:<br />
#!/bin/bash<br />
# set the battery charging thresholds to extend battery lifespan<br />
echo 40 > /sys/devices/platform/smapi/BAT0/start_charge_thresh<br />
echo 80 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh<br />
Set it runnable:<br />
[root ~]# '''chmod 744 /usr/sbin/set_battery_threshold'''<br />
Make this script run at startup by editing <code>/etc/rc.local</code>:<br />
#... other rc.local stuff<br />
'''/usr/sbin/set_battery_thresholds'''<br />
Make it run when a battery is inserted. This requires that [[acpid]] is installed and running. Edit <code>/etc/acpi/handler.sh</code>:<br />
#... other ACPI stuff<br />
battery)<br />
case "$2" in<br />
BAT0)<br />
case "$4" in<br />
00000000)<br />
;;<br />
00000001)<br />
'''/usr/sbin/set_battery_thresholds'''<br />
;;<br />
#... more ACPI stuff<br />
<br />
===Protect the Hard Disk from Drops===<br />
tp_smapi includes a driver to read the accelerometer in your laptop to detect drops and other events that could cause damage to your hard drive. See the [[HDAPS]] page for more information on this useful feature.<br />
<br />
==See Also==<br />
[http://www.thinkwiki.org/wiki/Tp_smapi tp_smapi on ThinkWiki]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Hard_Drive_Active_Protection_System&diff=58394Hard Drive Active Protection System2009-01-19T22:48:07Z<p>ColdPie: </p>
<hr />
<div>This page describes how to install HDAPS on your Arch Linux installation. HDAPS stands for "Hard Drive Active Protection System." Its purpose is to protect your hard drive from sudden shocks (such as dropping or banging your laptop on a desk). It does this by parking the disk heads, so that shocks don't cause them to crash into the drive's platters. Hopefully, this will prevent catastrophic failure.<br />
<br />
As of Linux 2.6.28, the kernel has the ability to park disk heads on demand. Previously, this had to be patched into the kernel. Thanks to the kernel devs' hard work, we no longer have to rebuild our kernel to use this feature. Obviously, this means you need to be running 2.6.28 to follow this guide.<br />
<br />
==Shock Detection==<br />
Your hardware needs to support some kind of shock detection. This is usually in the form of an accelerometer built into your laptop's motherboard. If you have the hardware, you also need a way to communicate what the hardware is detecting to your operating system. This section describes drivers to communicate the accelerometer's state to the OS so it can detect and protect against shocks.<br />
<br />
===tp_smapi===<br />
[[tp_smapi]] is a set of drivers for ThinkPad laptops. It is highly recommended if you have a ThinkPad, even if you don't plan to use HDAPS. Among a plethora of other useful things, tp_smapi represents the accelerometer output as joystick devices <code>/dev/js#</code> (Note! This could interfere with other joystick devices on your system). <br />
<br />
Install [http://aur.archlinux.org/packages.php?ID=3985 tp_smapi] from AUR. After installing, add <code>tp_smapi</code> to your <code>MODULES</code> array. After a reboot, this will activate most of the drivers, represented through the <code>/sys/devices/platform/smapi</code> filesystem.<br />
<br />
The kernel provides its own HDAPS drivers. For this reason, the HDAPS part of tp_smapi is built separately. Attempting to add <code>hdaps</code> to your <code>MODULES</code> array will result in the default drivers being loaded. This is not what we want, as we have our special ThinkPad HDAPS drivers. Instead, modify your /etc/rc.local and add the following line:<br />
<br />
insmod /lib/modules/2.6.28-ARCH/extra/hdaps.ko<br />
<br />
This will load the ThinkPad HDAPS module at the end of the initialization sequence.<br />
<br />
==Shock Protection==<br />
Now that your hardware is reporting its shock detection to the OS, we need to do something with this data. This section describes software utilities to transform the sensor output into shock protection.<br />
<br />
===hdapsd===<br />
hdapsd monitors the output of the HDAPS joystick devices to determine if a shock is about to occur, then tells the kernel to park the disk heads.<br />
<br />
Install [http://aur.archlinux.org/packages.php?ID=5401 hdapsd] from AUR. After installing, add <code>hdapsd</code> to your <code>DAEMONS</code> array. Also be sure to review <code>/etc/conf.d/hdapsd</code> to ensure that it's protecting the correct hard drive. After a reboot, your computer will now monitor the joystick devices and park your disk heads to protect it against shocks.<br />
<br />
Reboot your computer at this point.<br />
<br />
==GUI Utilities==<br />
Utilities exist to monitor hdapsd's status so you know what's going on while you're using your laptop. These are entirely optional, but very handy.<br />
<br />
===gnome-hdaps-applet===<br />
This is a GNOME panel applet (Note: XFCE can use GNOME panel applets) that represents the current status of your hard drive. If the disk heads are parked by hdapsd, this applet will reflect that. Unfortunately, the AUR project for gnome-hdaps-applet is very out of date and does not work any longer. This should be fixed, but for now, here's how to do it manually. Note that pacman '''will not''' manage these files. If you update this applet later, you'll have to manually remove and replace these files.<br />
<br />
First, grab the latest gnome-hdaps-applet sources from the [http://www.zen24593.zen.co.uk/hdaps/ this HDAPS mirror]. As of this writing, this is version <code>20081204</code>. Inflate these files, and follow the instructions in <code>INSTALL</code>. It's very straight-forward. When you're done, keep the <code>INSTALL</code> file around for future reference if you have to update or uninstall the applet later. Again, remember that pacman will not manage these files for you in any way.<br />
<br />
===khdapsmonitor===<br />
A KDE version exists as well. [http://aur.archlinux.org/packages.php?ID=12679 khdapsmonitor] in AUR. (Someone who uses KDE, please research and update this section.)<br />
<br />
==See Also==<br />
[http://www.thinkwiki.org/wiki/How_to_protect_the_harddisk_through_APS How to protect the harddisk through APS at ThinkWiki]<br />
<br />
[http://www.thinkwiki.org/wiki/HDAPS HDAPS at ThinkWiki]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Tp_smapi&diff=58393Tp smapi2009-01-19T22:44:39Z<p>ColdPie: New page: tp_smapi is a set of kernel modules that retrieves information and conveys commands to the hardware of ThinkPad laptops. This information is presented through the <code>/sys/devices/platf...</p>
<hr />
<div>tp_smapi is a set of kernel modules that retrieves information and conveys commands to the hardware of ThinkPad laptops. This information is presented through the <code>/sys/devices/platform/smapi</code> filesystem. Much like the <code>/proc</code> filesystem, you can read and write information to these files to get information about and send commands to the hardware. tp_smapi is highly recommended if you're using a ThinkPad laptop.<br />
<br />
==Installation==<br />
Install [http://aur.archlinux.org/packages.php?ID=3985 tp_smapi] from AUR. After installing, add tp_smapi to your MODULES array. After a reboot, this will activate most of the drivers, represented through the <code>/sys/devices/platform/smapi</code> filesystem.<br />
<br />
==Features==<br />
Here are a couple of useful things you can do using tp_smapi. Please feel free to add your own.<br />
<br />
===Control Battery Charging===<br />
It's bad for most laptop batteries to hold a full charge for long periods of time. You should try to keep your battery in the 40-80% charged range, unless you need the battery life for extended periods of time. tp_smapi lets you control the start and stop charging threshold to do just that. Run these commands to set these to good values:<br />
echo 40 > /sys/devices/platform/smapi/BAT0/start_charge_thresh<br />
echo 80 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh<br />
This will cause the battery to begin charging when it falls below 40% charge and stop charging once it exceeds 80% charge. This will extend the lifetime of your battery.<br />
<br />
Note that when you remove and re-insert the battery, these thresholds may be reset to their default values. To work around this, create a script to set these values, and make this script run both at startup and when a battery is inserted. More specific instructions follow.<br />
<br />
Create a script <code>/usr/sbin/set_battery_thresholds</code>:<br />
#!/bin/bash<br />
# set the battery charging thresholds to extend battery lifespan<br />
echo 40 > /sys/devices/platform/smapi/BAT0/start_charge_thresh<br />
echo 80 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh<br />
Set it runnable:<br />
[root ~]# '''chmod 744 /usr/sbin/set_battery_threshold'''<br />
Make this script run at startup by editing <code>/etc/rc.local</code>:<br />
#... other rc.local stuff<br />
'''/usr/sbin/set_battery_thresholds'''<br />
Make it run when a battery is inserted. This requires that [[acpid]] is installed and running. Edit <code>/etc/acpi/handler.sh</code>:<br />
#... other ACPI stuff<br />
battery)<br />
case "$2" in<br />
BAT0)<br />
case "$4" in<br />
00000000)<br />
;;<br />
00000001)<br />
'''/usr/sbin/set_battery_thresholds'''<br />
;;<br />
#... more ACPI stuff<br />
<br />
===Protect the Hard Disk from Drops===<br />
tp_smapi includes a driver to read the accelerometer in your laptop to detect drops and other events that could cause damage to your hard drive. See the [[HDAPS]] page for more information on this useful feature.<br />
<br />
==See Also==<br />
[http://www.thinkwiki.org/wiki/Tp_smapi tp_smapi on ThinkWiki]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Hard_Drive_Active_Protection_System&diff=58391Hard Drive Active Protection System2009-01-19T22:25:00Z<p>ColdPie: New page: This page describes how to install HDAPS on your Arch Linux installation. HDAPS stands for "Hard Drive Active Protection System." Its purpose is to protect your hard drive from sudden sh...</p>
<hr />
<div>This page describes how to install HDAPS on your Arch Linux installation. HDAPS stands for "Hard Drive Active Protection System." Its purpose is to protect your hard drive from sudden shocks (such as dropping or banging your laptop on a desk). It does this by parking the disk heads, so that shocks don't cause them to crash into the drive's platters. Hopefully, this will prevent catastrophic failure.<br />
<br />
As of Linux 2.6.28, the kernel has the ability to park disk heads on demand. Previously, this had to be patched into the kernel. Thanks to the kernel devs' hard work, we no longer have to rebuild our kernel to use this feature. Obviously, this means you need to be running 2.6.28 to follow this guide.<br />
<br />
==Shock Detection==<br />
Your hardware needs to support some kind of shock detection. This is usually in the form of an accelerometer built into your laptop's motherboard. If you have the hardware, you also need a way to communicate what the hardware is detecting to your operating system. This section describes drivers to communicate the accelerometer's state to the OS so it can detect and protect against shocks.<br />
<br />
===tp_smapi===<br />
[[tp_smapi]] is a set of drivers for ThinkPad laptops. Among a plethora of other useful things, tp_smapi represents the accelerometer output as joystick devices <code>/dev/js#</code> (Note! This could interfere with other joystick devices on your system). tp_smapi is highly recommended if you have a ThinkPad, even if you don't plan to use HDAPS.<br />
<br />
Install [http://aur.archlinux.org/packages.php?ID=3985 tp_smapi] from AUR. After installing, add <code>tp_smapi</code> to your <code>MODULES</code> array. After a reboot, this will activate most of the drivers, represented through the <code>/sys/devices/platform/smapi</code> filesystem.<br />
<br />
The kernel provides its own HDAPS drivers. For this reason, the HDAPS part of tp_smapi is built separately. Attempting to add <code>hdaps</code> to your <code>MODULES</code> array will result in the default drivers being loaded. This is not what we want, as we have our special ThinkPad HDAPS drivers. Instead, modify your /etc/rc.local and add the following line:<br />
<br />
insmod /lib/modules/2.6.28-ARCH/extra/hdaps.ko<br />
<br />
This will load the ThinkPad HDAPS module at the end of the initialization sequence.<br />
<br />
==Shock Protection==<br />
Now that your hardware is reporting its shock detection to the OS, we need to do something with this data. This section describes software utilities to transform the sensor output into shock protection.<br />
<br />
===hdapsd===<br />
hdapsd monitors the output of the HDAPS joystick devices to determine if a shock is about to occur, then tells the kernel to park the disk heads.<br />
<br />
Install [http://aur.archlinux.org/packages.php?ID=5401 hdapsd] from AUR. After installing, add <code>hdapsd</code> to your <code>DAEMONS</code> array. Also be sure to review <code>/etc/conf.d/hdapsd</code> to ensure that it's protecting the correct hard drive. After a reboot, your computer will now monitor the joystick devices and park your disk heads to protect it against shocks.<br />
<br />
Reboot your computer at this point.<br />
<br />
==GUI Utilities==<br />
Utilities exist to monitor hdapsd's status so you know what's going on while you're using your laptop. These are entirely optional, but very handy.<br />
<br />
===gnome-hdaps-applet===<br />
This is a GNOME panel applet (Note: XFCE can use GNOME panel applets) that represents the current status of your hard drive. If the disk heads are parked by hdapsd, this applet will reflect that. Unfortunately, the AUR project for gnome-hdaps-applet is very out of date and does not work any longer. This should be fixed, but for now, here's how to do it manually. Note that pacman '''will not''' manage these files. If you update this applet later, you'll have to manually remove and replace these files.<br />
<br />
First, grab the latest gnome-hdaps-applet sources from the [http://www.zen24593.zen.co.uk/hdaps/ this HDAPS mirror]. As of this writing, this is version <code>20081204</code>. Inflate these files, and follow the instructions in <code>INSTALL</code>. It's very straight-forward. When you're done, keep the <code>INSTALL</code> file around for future reference if you have to update or uninstall the applet later. Again, remember that pacman will not manage these files for you in any way.<br />
<br />
===khdapsmonitor===<br />
A KDE version exists as well. [http://aur.archlinux.org/packages.php?ID=12679 khdapsmonitor] in AUR. (Someone who uses KDE, please research and update this section.)<br />
<br />
==See Also==<br />
[http://www.thinkwiki.org/wiki/How_to_protect_the_harddisk_through_APS How to protect the harddisk through APS at ThinkWiki]<br />
<br />
[http://www.thinkwiki.org/wiki/HDAPS HDAPS at ThinkWiki]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=GAIM&diff=55938GAIM2008-12-21T17:34:02Z<p>ColdPie: Redirecting to Pidgin</p>
<hr />
<div>#REDIRECT [[Pidgin]]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Screen_Irssi_Bitlbee&diff=55305Screen Irssi Bitlbee2008-12-12T17:49:28Z<p>ColdPie: New page: Using GNU Screen, Irssi, Bitlbee, and SSH together allows you to have a persistent connection to IRC servers, AOL Instant Messenger, and MSN Instant Messenger. Via SSH, you can access thi...</p>
<hr />
<div>Using GNU Screen, Irssi, Bitlbee, and SSH together allows you to have a persistent connection to IRC servers, AOL Instant Messenger, and MSN Instant Messenger. Via SSH, you can access this persistent chat suite from anywhere. Putting the pieces together is not difficult, and this page will guide you through it.<br />
<br />
=Components=<br />
==GNU Screen==<br />
<br />
First we'll introduce [[Screen Tips|GNU Screen]]. Screen lets you keep shells open, even when you're not actively using them. We'll be using it here to keep our IRC session persistent so that we can reconnect to it from anywhere without having to close the IRC client. Read the wiki page and man page for GNU Screen for more information.<br />
<br />
==Irssi==<br />
<br />
[[Irssi]] is a command-line IRC client. It's very flexible and scriptable. We'll be using it, obviously, as our IRC client.<br />
<br />
==Bitlbee==<br />
<br />
[[Bitlbee]] is an interesting project. It sets up an IRC server on your local machine, which connects to various instant messenger protocols, and represents logged-in users as IRC users.<br />
<br />
==SSH==<br />
<br />
Everyone knows what [[SSH]] is. This will let us use our persistent chat suite from anywhere with web access.<br />
<br />
=Setting it up=<br />
==Installing==<br />
First, update your system and install all of the required packages:<br />
pacman -Syu<br />
pacman -S openssh irssi screen bitlbee<br />
<br />
==Configuring SSH==<br />
Follow the directions on [[SSH|SSH's wiki page]] to set up SSH. It's far too involved to summarize here.<br />
<br />
==Configuring bitlbee==<br />
The only application which really requires you to configure is Bitlbee. You can follow the directions on [[Bitlbee|Bitlbee's wiki page]] if you like. All you really need to do is go through /etc/bitlbee/bitlbee.conf and configure it how you like. Below are some modifications worth pointing out.<br />
<br />
This will have Bitlbee run as a daemon, which forks a new process for each user that joins. This is simpler than running it through xinetd, so I suggest it.<br />
RunMode = ForkDaemon<br />
<br />
This will have the daemon drop root priveledges after it launches on boot. Do this for security; there's no reason for Bitlbee to run as root.<br />
User = bitlbee<br />
<br />
Be sure to change the password here.<br />
OperPassword = <br />
<br />
==Using Irssi in Screen==<br />
Open up a terminal and run screen. After the copyright message (read the wiki to disable that message), you should find yourself at a plain terminal. Launch irssi in this terminal.<br />
<br />
Irssi is a full-fledged IRC client, so we can't list a complete tutorial here. Use Google to find more information on what irssi can do for you. Now's the time to connect to whatever IRC networks you like.<br />
<br />
===Connecting to Bitlbee===<br />
Bitlbee sets up an IRC server on your local machine. To connect to it, run this in irssi:<br />
/connect localhost <optional port><br />
<br />
You should immediately join a channel called &bitlbee. Here you'll see a brief introduction to Bitlbee. Type help to get started. Set up Bitlbee to connect to your instant messenger accounts. You'll see your contacts join the channel.<br />
<br />
=Using It=<br />
Now that we've got Irssi, Bitlbee, and Screen all running, what can we do with it?<br />
<br />
First, the whole point of this excersize was to create a persistent chat session that can be accessed from anywhere. From another computer, SSH into your server. Type in `screen -raAd` and watch as irssi, with all of your channels and IM connections, pops up. Any messages left for you while you were away are visible, just as if you were at your server.<br />
<br />
==Launching the Setup==<br />
Since it's a pain to manually connect to each IRC network, join channels, connect to Bitlbee, and have Bitlbee connect to your IM accounts every time you you log in, set up some scripts to help you out.<br />
<br />
First, create a Screen initialization file. Here's mine:<br />
# ~/irc_screen<br />
source ~/.screenrc<br />
screen -t IRC 1 irssi<br />
<br />
This will launch irssi in window 1 and title the Screen session 'IRC'.<br />
<br />
I then set up a short bash script to launch Screen with that config file:<br />
#!/bin/bash<br />
screen -d -m -c ~/irc_screen<br />
The command line switches: "-d -m" starts screen in detached mode, so that it launches in the background. "-c ~/irc_screen" uses ~/irc_screen as the rc file for this session.<br />
<br />
To launch and connect to the Screen session:<br />
~/bin/irc_start<br />
screen -raAd<br />
<br />
==Doing More==<br />
Look into configuring irssi to behave more like you want:<br />
http://www.quadpoint.org/articles/irssi</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Bitlbee&diff=55303Bitlbee2008-12-12T17:18:37Z<p>ColdPie: </p>
<hr />
<div>[[Category:Internet and Email (English)]]<br />
[[Category:HOWTOs (English)]]<br />
= About =<br />
<br />
[http://www.bitlbee.org/main.php/news.r.html Bitlbee] is a "console-based IRC to IM chatting gateway, including ICQ/MSN/Jabber". Basically, it allows the user to interact with popular chat networks (ICQ, MSN, Jabber, AIM, YIM) within their IRC client.<br />
<br />
The users' buddies appear as normal IRC users in a channel and conversations use the private message facility of IRC.<br />
<br />
<br />
= Setup =<br />
<br />
First, download and install the package using pacman:<br />
<br />
# pacman -S bitlbee<br />
<br />
Bitlbee can now run as a daemon of its own! Open up /etc/bitlbee/bitlbee.conf to browse through the settings. Edit the "RunMode" line to "ForkDaemon", then run<br />
/etc/rc.d/bitlbee start<br />
to start the Bitlbee server. Of course, add bitlbee to your DAEMONS array in /etc/rc.conf to start the server on boot. Note that just starting the server does not log you in to any of your messenger accounts! You must join a channel and issue commands.<br />
<br />
= Configuration =<br />
You are now able to connect to this in an IRC client. To connect, just connect to localhost using your favorite IRC client.<br />
<br />
Hopefully this will connect and you should immediately join a channel called '&bitlbee'. When you join this channel it will tell to type 'Help' if you're new... type 'Help' ;)<br />
<br />
Read through the help offered by Bitlbee to get started. There are some great guides online too:<br />
<br />
http://quark.humbug.org.au/publications/internet/bitlbee.pdf<br />
<br />
http://princessleia.com/bitlbee.php<br />
<br />
= How to connect to Jabber using your Gmail account =<br />
In your control channel do the following:<br />
account add jabber username@gmail.com mypasswd<br />
<br />
After root responds with "Account successfully added" you can check your accounts with "account list".<br />
<br />
<@user> account list <br />
<@root> 0. JABBER, username@gmail.com (connected) <br />
<@root> End of account list<br />
<br />
After you have added the account, type "account on 0" and it should log in:<br />
<br />
<@user> account on 0 <br />
<@root> JABBER(username@gmail.com) - Logging in: Connecting <br />
<@root> JABBER(username@gmail.com) - Logging in: Connected <br />
<@root> JABBER(username@gmail.com) - Logging in: Requesting Authentication Method<br />
<@root> JABBER(username@gmail.com) - Logging in: Authenticating <br />
<@root> JABBER(username@gmail.com) - Logged in<br />
<br />
If you get errors like the following:<br />
<br />
<@user> account on 0 <br />
<@root> JABBER(username@gmail.com) - Logging in: Connecting<br />
<@root> JABBER(username@gmail.com) - Logging in: Connected<br />
<@root> JABBER(username@gmail.com) - Logging in: Requesting Authentication Method<br />
<@root> JABBER(username@gmail.com) - Logging in: Authenticating<br />
<@root> JABBER(username@gmail.com) - Login error: Error 403: Unknown error<br />
<@root> JABBER(username@gmail.com) - Signing off...<br />
<br />
Switching the domain from "gmail.com" to "googlemail.com" may help.<br />
This seems to be the case for some European countries, especially Germany where Google doesn't own the trademark for the name ''Gmail'' [http://www.theregister.co.uk/2007/01/31/google_looses_trademark_battle/].<br />
<br />
The easiest way to change your account settings is to simply delete the account you created and add it again.<br />
account del 0<br />
account add jabber username@googlemail.com mypasswd<br />
<br />
If you are still unable to connect, try switching the port to 5222. For some reason some people must connect on 5223 while others have to connect on 5222. There appears to be no way to know which one to use other than trial and error.</div>ColdPiehttps://wiki.archlinux.org/index.php?title=VMware&diff=54367VMware2008-11-30T16:12:44Z<p>ColdPie: </p>
<hr />
<div>[[Category:Emulators (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|:Installing_VMware Server 1.0.x or Workstation 6.0.x}}<br />
{{i18n_entry|简体中文|:安装VMWare}}<br />
{{i18n_entry|Italiano|:Installing_VMware (Italiano)}}<br />
{{i18n_links_end}}<br />
[http://www.vmware.com/ VMware] installs on [[Arch Linux]] pretty well, but its not totally straight forward.<br />
<br />
==VMWare Workstation Installation==<br />
The following is from the VMWare Workstation AUR user comments, by user whompus. It describes how to install VMWare Workstation 6.5.x on either architecture.<br />
<br />
As a temp measure use this method to install 6.5. Note that it will '''not''' install with pacman, so the files installed will '''not''' be traceable/removable with pacman.<br />
<br />
To install Workstation on a Linux host using a bundle<br />
<br />
1. Download VMware-Workstation-6.5.xxxxxx.bundle. Replace xxxxx for whichever minor version & architecture.<br />
<br />
2. In a terminal cd to the directory where you downloaded the file.<br />
<br />
3. Become root to perform the initial installation steps:<br />
# mkdir -p /etc/rc.d/vmware.d/rc{0,1,2,3,4,5,6}.d<br />
# sh VMware-Workstation-6.5.xxxxxx.bundle --console --custom<br />
<br />
4. Read & accept the EULA to continue.<br />
<br />
5. Accept the default settings until it prompts for System service runlevels then set to:<br />
/etc/rc.d/vmware.d/<br />
<br />
6. For System service scripts set to:<br />
/etc/rc.d<br />
<br />
7. (Optional) Enter the directory path to the Integrated Virtual Debugger for Eclipse if Eclipse is installed.<br />
<br />
8. Mash enter to install<br />
<br />
9. Open Workstation (<code>vmware</code> in the console) to configure & use!<br />
<br />
==VMWare Server Installation==<br />
'''NOTE''' I would highly recommend using VMWare Server 2 on 2.6.27 as it actually builds. It also does not appear to require a patch.<br />
<br />
You can use the [http://aur.archlinux.org/packages.php?do_Details=1&ID=6182&O=0&L=0&C=0&K=vmware&SB=n&SO=a&PP=25&do_MyPackages=0&do_Orphans=0&SeB=nd AUR] or manually install [http://www.vmware.com/download/server/ VMware Server] downloaded from [http://www.vmware.com/ VMware.com]. This guide shows you how to install the manually downloaded VMware server tarball, assuming you are running Voodoo or newer (Duke) with kernel version 2.6.20+ '''32-bit'''.<br />
<br />
===Requirements:===<br />
* Root access. Either 'sudo' or 'su'. For this guide, I will be using 'sudo'.<br />
* [http://archlinux.org/packages/search/?repo=all&category=all&q=xinetd&lastupdate=&limit=50 Xinetd] is installed, up and running.<br />
* The X-libraries libxtst, libxt and libxrender installed<br />
* [http://www.vmware.com/download/server/ VMware server tarball]; latest is 1.0.4 build 56528 as of this writing.<br />
* <strike>VMware server [http://www.vmware.com/community/thread.jspa?messageID=76957&tstart=0 any-to-any]" patch: [http://platan.vc.cvut.cz/ftp/pub/vmware mirror 1] and [ftp://ftp.cvut.cz/vmware mirror 2]. Note: For server 1.0.4 build 56528 you need patch vmware-any-any-update113.tar.bz2, which is on mirror 1 only.</strike><br />
* UPDATE: With 2.6.24 you need this [http://rtr.ca/vmware-2.6.24/ patch] (vmware-any-any-update115a.tgz)<br />
* UPDATE: With 2.6.25 you need also this [http://blog.creonfx.com/temp/vmware-any-any-update-117-very-ALPHA.tgz patch] (vmware-any-any-update-117-very-ALPHA)<br />
* Compatible with VMware Workstation >= 6.0.2 Build 59824 on Linux 2.6.25<br />
* UPDATE: With 2.6.26 you need this [http://vmkernelnewbies.googlegroups.com/web/vmware-any-any-update117d.tar.gz patch] (vmware-any-any-update117d.tar.gz), the VMware version 6.0.5 doesn't need the patch, the version for vmmon e.g. in 117d is even too old (168, need 169!)<br />
* UPDATE: With 2.6.26 and VMWare 6.5 _no_ patch is needed anymore (6.5.0 build-118166). The graphical installer works just fine and all the modules work out of the box. Follow the instructions below for the directory containing the init-scripts.<br />
<br />
===Instructions:===<br />
* Run '''''sudo mkdir -p /etc/rc.d/vmware.d/rc{0,1,2,3,4,5,6}.d''''' to create VMware runlevel directories.<br />
* Run '''''sudo ln -s /bin/lsmod /sbin/''''' to create symlink for lsmod.<br />
* Extract VMware server tarball somewhere... i.e. /tmp/.<br />
* Run '''''cd /tmp/vmware-server-distrib;sudo ./vmware-install.pl'''''. I used '''''/home/vmware/bin''''' for installation.<br />
* When it asks where the directories for ''rc0.d'' thru ''rc6.d'' are, use '''''/etc/rc.d/vmware.d'''''.<br />
* When it asks where the init directory is, use '''''/etc/rc.d'''''.<br />
* '''*QUIT*''' when it asks you if you want to run VMware configuration for the first time.<br />
* Extract VMware server any-to-any patch somewhere... i.e. /tmp/.<br />
* Run '''''cd /tmp/vmware-any-any-update*REV*;sudo ./runme.pl'''''. This will patch VMware server modules to allow Linux kernel 2.6.20 compilation.<br />
* For Linux 2.6.25 additionally to the previous patch115a or 116 you need to manually patch with 117_Alpha.<br />
* For 2.6.25 extract 117 to the location '''''tar xzf vmware-any-any-update-117-very-ALPHA.tgz -C /usr/lib/vmware/modules/source/<br />
* For 2.6.25 patch '''''cd /usr/lib/vmware/modules/source/''''' and run'''''./vmware-2.6.25.sh''''' and continue with next step.<br />
* Run '''''cd /home/vmware/bin;sudo ./vmware-config.pl''''' to compile VMware modules.<br />
<br />
== Running ==<br />
<br />
It's a possibility the first time you try to run Vmware server it'll throw an error stating something about "Unable to power virtual machine". Stop the VMware server and restart xinetd wtih '''''/etc/rc.d/vmware stop;wait;/etc/rc.d/xinetd restart'''''.<br />
<br />
Rerun '''''sudo /home/vmware/bin/vmware-config.pl''''' again. If this still fails, restart your computer and do the above again. It should be fixed.<br />
<br />
There is now a <code>vmware</code> init script in <code>/etc/rc.d</code>. You can add this to your daemons list if you want. I personally dont do this, but if you intend to use the vmware's network when not actually using vmware, then you will need to do this. You will need to start it before you can run vmware though.<br />
<br />
There is a problem with vmware unable to run correctly after a reboot. To fix this edit <code>/etc/rc.d/vmware</code>, find the text below<br />
case "$1" in<br />
start)<br />
and put<br />
rm /etc/vmware/not_configured<br />
immediately after that line.<br />
<br />
To start vmware, you just do <code>vmware</code> from a console window, or create a shortcut or menu item however you like.<br />
<br />
'''Some notes:'''<br />
<br />
Leave the <code>/etc/rc.d/vmware.d</code> directory there, because it is needed whenever you perform <code>vmware-config.pl</code>.<br />
<br />
Remember, if the kernel is changed or updated, you will need to run <code>vmware-config.pl</code> again.<br />
<br />
== Kernel 2.6 and udev ==<br />
<br />
Follow the steps above and then:<br />
<br />
'''1. Modify udev config'''<br />
<br />
Edit <code>/etc/udev/rules.d/00-myrules.rules</code> and add 2 lines:<br />
# tty devices<br />
KERNEL="tty<nowiki>[[0-9]]</nowiki>*", NAME="vc/%n", SYMLINK="%k"<br />
<br />
# floppy devices<br />
KERNEL="fd<nowiki>[[0-9]]</nowiki>*", NAME="floppy/%n" , SYMLINK="fd%n"<br />
<br />
'''2. Start/stop script'''<br />
<br />
It takes care of devices and starts vmware, also stops vmware and removes dev entries. Call it, for example, <code>mkvmdev</code>, chmod it <code>755</code> and put in <code>/etc/rc.d</code>:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
case "$1" in<br />
start)<br />
stat_busy "Creating /dev entries and starting VMware"<br />
for i in `seq 0 9`; do<br />
mknod /dev/vmnet$i c 119 $i<br />
chmod 0600 /dev/vmnet$i<br />
done<br />
for i in `seq 0 3`; do<br />
mknod /dev/parport$i c 99 $i<br />
chmod 0600 /dev/parport$i<br />
done<br />
mknod /dev/vmmon c 10 165<br />
chmod 0660 /dev/vmmon<br />
/etc/rc.d/vmware start<br />
;;<br />
<br />
stop)<br />
stat_busy "Stopping VMware and removing /dev entries"<br />
/etc/rc.d/vmware stop<br />
rm /dev/vmmon<br />
for i in `seq 0 3`; do<br />
rm /dev/parport$i<br />
done<br />
for i in `seq 0 9`; do<br />
rm /dev/vmnet$i<br />
done<br />
;;<br />
<br />
restart)<br />
$0 stop<br />
$0 start<br />
;;<br />
<br />
*)<br />
echo "usage: $0 {start|stop|restart}"<br />
esac<br />
exit 0<br />
</pre><br />
<br />
'''3. Modify <code>/etc/rc.conf</code>.''' (*Note - this step is optional! See also the notes under the "Running" section above)<br />
<br />
Add <code>mkvmdev</code> to daemons in your <code>rc.conf</code>, and remember to remove <code>vmware</code> from <code>rc.conf</code>. Or if you prefer, you can delete the lines that launch vmware from <code>mkvmdev</code> and leave your original <code>vmware</code> in <code>rc.conf</code> - your choice.<br />
<br />
-----<br />
<br />
'''Comments:'''<br />
<br />
hi guys, a couple of quick questions:<br><br />
- why is /dev/vmmon chmod 0660, as opposed to the rest (0600)?<br><br />
- i suppose /dev/vmmon should be "rm"-ed as well in the "stop" section for the script above? (that line is missing) - FIXED<br />
<br />
== vmware and kernel 2.6.20 compile modules problem ==<br />
<br />
Below is a solution for compiling the vmware modules on kernel 2.6.20.<br />
<br />
<pre><br />
cd /usr/lib/vmware/modules/source/<br />
sudo tar -xvf vmmon.tar<br />
cd vmmon-only<br />
sudo vi include/compat_kernel.h<br />
<br />
Find this:<br />
<br />
#define __NR_compat_exit __NR_exit<br />
static inline _syscall1(int, compat_exit, int, exit_code);<br />
<br />
and change the static inline ..... line to:<br />
<br />
int compat_exit(int exit_code);<br />
<br />
Then tar up the vmmon-only directory again.<br />
<br />
cd .. #go back to the source directory<br />
tar -cf vmmon.tar vmmon-only<br />
<br />
Finally, run vmware-config.pl<br />
</pre><br />
<br />
== vmware and kernel 2.6.16 compile modules problem ==<br />
'''PROBLEM''': kernel 2.6.16-x - vmware or vmwareplayer complains that headers are incorect.<br><br />
'''FIX''': You need [http://knihovny.cvut.cz/ftp/pub/vmware/vmware-any-any-update101.tar.gz vmware-any-any-update] patch [ftp://ftp.cvut.cz/vmware/vmware-any-any-update101.tar.gz mirror here] [http://www.inarad.ro/soft/vmware/vmware-any-any-update101.tar.gz or here].<br> Just untar the archive and run ./runme.pl as root - and you-re happy again!<br />
<br />
== vmware on kernel 2.6.22 ==<br />
May not work properly yet. Apply the patch from http://knihovny.cvut.cz/ftp/pub/vmware/vmware-any-any-update112.tar.gz , replace vmnet.tar with http://npw.net/~phbaer/vmnet.tar and reinstall. Note: this is an '''ugly hack''', please dont put it into production systems. Some guest OS'es may have crashes and networking problems with this. '''Dont tell us that you havent been warned'''<br />
<br />
== vmware and kernel 2.6.24 compile modules problem ==<br />
May not work properly yet. Apply the patch from http://bio.artcradle.com/temp/vault/vmware-any-any-update-116.tgz (untar, run runme.pl script) Note: this is an '''ugly hack''', please don't put it into production systems. Some guest OS'es may have crashes and networking problems with this. '''Don't tell us that you haven't been warned'''<br />
<br />
== vmware and kernel 2.6.25 compile modules problem ==<br />
There are extra steps required for Vmware WKS 6.0.3 build 80004, should be the same for VMware Server<br />
# Install and patch as described (use vmware-any-any-update-116.tgz)<br />
# Download the [http://blog.creonfx.com/temp/vmware-any-any-update-117-very-ALPHA.tgz patch117]vmware-any-any-update-117-very-ALPHA.tgz <br />
# Extract the archive in /usr/lib/vmware/modules/source <br />
# Run vmware-2.6.25.sh and then vmware-config.pl<br />
<br />
== vmware and kernel 2.6.26 compile modules problem ==<br />
If after compiling the modules following the method for 2.6.25 you receive the "Version mismatch with vmmon module:" error when powering on a virtual machine you will need to take one additional step.<br />
<br />
<pre><br />
<br />
cd /usr/lib/vmware/moduels/source/;<br />
sudo tar -xvf vmmon.tar;<br />
sudo vi vmmon-only/include/iocontrols.h;<br />
<br />
<br />
Find the line 48:<br />
<br />
#define VMMON_VERSION (161 << 16 | 0)<br />
<br />
and change to <br />
<br />
#define VMMON_VERSION (167 << 16 | 0)<br />
<br />
Save and exit.<br />
<br />
<br />
sudo tar -cf vmmon.tar vmmon-only;<br />
<br />
Finally, run vmware-config.pl.<br />
<br />
</pre><br />
<br />
== slow networking between host and guest ==<br />
"Those oversized improperly checksummed packets are TCP Segmentation Offload packets. Use ''''ethtool -k eth0 tso off'''' to disable TSO on eth0 (or any other interface which you want to get bridged). At this moment vmnet does not understand TSO, and in addition to that it is silly to use TSO together with bridged networking as vmnet will have to split such packet anyway to pass it to the guest, so splitting will be done anyway, and in addition to it kernel will have to prepare metadata about TCP stream for hardware, so you'll probably get worse performance with TSO enabled than with disabled when you'll have some guest running."<br />
<br />
'''NOTE:''' ''ethtool is on extra packages''<br />
<br />
== Samba issues ==<br />
The guest os under vmware cannot see a samba share running on the linux host. To fix this problem, edit /etc/samba/smb.conf and make some changes under [global]. The following are suggested:<br><br />
workgroup = YOUR_WORKGROUP<br><br />
netbios name = YOUR_SERVER_NAME<br><br />
encrypt passwords = yes<br><br />
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192<br><br />
interfaces = eth0 vmnet1 vmnet8<br><br />
sysv shm key=/dev/vmnet1<br><br />
bind interfaces only = true<br><br />
<br />
== Connecting Remotely ==<br />
If you setup a server that you would like to connect to remotely, please add the following to <b>/etc/hosts.allow</b>:<br />
<pre>vmware-authd: ALL</pre><br />
This will enable <b>xinetd</b> to allow connections from a remote vmware client.<br><br />
<br><br />
If this condition is not met, you may see in your <b>/var/log/everything.log</b>:<br />
<pre>Feb 4 03:34:12 jeffc xinetd[7232]: libwrap refused connection to vmware-authd (libwrap=vmware-authd) from 192.168.1.1</pre></div>ColdPiehttps://wiki.archlinux.org/index.php?title=Advanced_Linux_Sound_Architecture&diff=51428Advanced Linux Sound Architecture2008-10-18T17:14:59Z<p>ColdPie: </p>
<hr />
<div>[[Category:Sound (English)]]<br />
[[Category:Audio/Video (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|ALSA}}<br />
{{i18n_entry|Español|ALSA (Español)}}<br />
{{i18n_entry|Deutsch|ALSA Einrichten}}<br />
{{i18n_entry|Italiano|ALSA (Italiano)}}<br />
{{i18n_entry|Nederlands|ALSA instellen}}<br />
{{i18n_entry|Русский|ALSA_(Russian)}}<br />
{{i18n_entry|Slovensky|Nastavenie ALSA}}<br />
{{i18n_entry|Česky|ALSA (Česky)}}<br />
{{i18n_entry|中文(简体)|设置ALSA}}<br />
{{i18n_entry|עברית|הגדרת ALSA}}<br />
{{i18n_entry|Рolski|ALSA Setup (Polski)}}<br />
{{i18n_entry|Português do Brasil|Instalação ALSA}}<br />
{{i18n_entry|ไทย|ALSA Setup (ไทย)}}<br />
{{i18n_entry|Türkçe|ALSA (Türkçe)}}<br />
{{i18n_links_end}}<br />
<br />
= Introduction =<br />
The Advanced Linux Sound Architecture (ALSA) is a Linux kernel component intended to provide device drivers for sound cards.<br />
<br />
See [[OSS]] if you are looking for alternatives.<br />
<br />
This document tells how to get ALSA working with 2.6 kernels. Also see how to <br />
[[Allow_multiple_programs_to_play_sound_at_once|allow multiple programs to play sound at once]].<br />
<br />
=Installation=<br />
<br />
==Kernel drivers==<br />
<br />
ALSA has been included in the 2.6 kernels and is included in all arch '''kernel26*''' packages. If you build a custom kernel, do not forget to enable the correct ALSA driver.<br />
<br />
All necessary modules should be detected and loaded automatically by udev. No special configuration has to be done unless you use ISA cards. '''NEVER''' use alsaconf if you have a PCI or ISAPNP sound card, as the entries alsaconf adds to the modprobe.conf file might break udev's autodetection.<br />
<br />
==Userspace utilities==<br />
<br />
* Required for native ALSA programs and administration<br />
# pacman -Sy alsa-lib alsa-utils<br />
* Recommended if you want to use applications with OSS sound support in combination with dmix:<br />
# pacman -S alsa-oss<br />
<br />
All ALSA programs will most likely have alsa-lib as a dependency.<br />
<br />
=Configuration=<br />
<br />
==Making sure the sound modules are loaded==<br />
<br />
You can assume that udev will autodetect your sound properly, including the OSS compatibility modules. You can check this with the command<br />
<br />
$ lsmod|grep '^snd'<br />
snd_usb_audio 69696 0 <br />
snd_usb_lib 13504 1 snd_usb_audio<br />
snd_rawmidi 20064 1 snd_usb_lib<br />
snd_hwdep 7044 1 snd_usb_audio<br />
snd_seq_oss 29412 0 <br />
snd_seq_midi_event 6080 1 snd_seq_oss<br />
snd_seq 46220 4 snd_seq_oss,snd_seq_midi_event<br />
snd_seq_device 6796 3 snd_rawmidi,snd_seq_oss,snd_seq<br />
snd_pcm_oss 45216 0 <br />
snd_mixer_oss 15232 1 snd_pcm_oss<br />
snd_intel8x0 27932 0 <br />
snd_ac97_codec 87648 1 snd_intel8x0<br />
snd_ac97_bus 1792 1 snd_ac97_codec<br />
snd_pcm 76296 4 snd_usb_audio,snd_pcm_oss,snd_intel8x0,snd_ac97_codec<br />
snd_timer 19780 2 snd_seq,snd_pcm<br />
snd 43776 12 snd_usb_audio,snd_rawmidi,snd_hwdep,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer<br />
snd_page_alloc 7944 2 snd_intel8x0,snd_pcm<br />
<br />
If the output looks similar, your sound drivers have been successfully autodetected (note that in this case, snd_intel8x0 and snd_usb_audio are the drivers for the hardware devices). You might also want to check the directory '''/dev/snd''' for the right device files:<br />
<br />
$ ls -l /dev/snd/<br />
total 0<br />
crw-rw---- 1 root audio 116, 0 Apr 8 14:17 controlC0<br />
crw-rw---- 1 root audio 116, 32 Apr 8 14:17 controlC1<br />
crw-rw---- 1 root audio 116, 24 Apr 8 14:17 pcmC0D0c<br />
crw-rw---- 1 root audio 116, 16 Apr 8 14:17 pcmC0D0p<br />
crw-rw---- 1 root audio 116, 25 Apr 8 14:17 pcmC0D1c<br />
crw-rw---- 1 root audio 116, 56 Apr 8 14:17 pcmC1D0c<br />
crw-rw---- 1 root audio 116, 48 Apr 8 14:17 pcmC1D0p<br />
crw-rw---- 1 root audio 116, 1 Apr 8 14:17 seq<br />
crw-rw---- 1 root audio 116, 33 Apr 8 14:17 timer<br />
<br />
If you have at least the devices '''controlC0''' and '''pcmC0D0p''' or similar, then your sound modules have been detected and loaded properly.<br />
<br />
<br />
If this is not the case, your sound modules have not been detected properly. '''If you want any help on IRC or the forums, please post the output of the above commands.''' To solve this, you can try loading the modules manually:<br />
<br />
* Locate the module for your soundcard: [http://www.alsa-project.org/main/index.php/Matrix:Main ALSA Soundcard Matrix] The module will be prefixed with 'snd-' (for example: 'snd-via82xx').<br />
* Load modules:<br />
# modprobe snd-NAME-OF-MODULE<br />
# modprobe snd-pcm-oss<br />
* Check for the device files in '''/dev/snd''' (see above) and/or try if '''alsamixer''' or '''amixer''' have reasonable output.<br />
* Add '''snd-NAME-OF-MODULE''' and '''snd-pcm-oss''' to the list of MODULES in '''/etc/rc.conf''' to ensure they are loaded next time (make sure '''snd-NAME-OF-MODULE''' is before '''snd-pcm-oss''').<br />
<br />
==Unmute the channels and test==<br />
<br />
In this section, we assume that you are logged in as root. If you want to perform these steps as an unprivileged user, you have to skip to the next section ''Setup Permissions'' first.<br />
<br />
* Unmute Soundcard<br />
<br />
The current version of ALSA installs with all channels '''muted by default''', so even if installation completes successfully and all devices are working properly you will hear no sound. You will need to unmute the channels manually. It is recommended to use '<code>alsamixer</code>' to accomplish this. From the alsamixer text ui, the label "MM" below a channel indicates that the channel is muted, and "00" indicates that it is open. Press the 'm' key to toggle MM/00. Use arrow-keys left and right to navigate through the channels and the arrow-keys up and down to adjust the volume. Such things as Master and PCM and possibly Speaker will need to unmuted for your sound to work.<br><br><br />
'''NOTE:''' When using '''<code>amixer</code>''', be sure to '''unmute''' as well as bring volumes up to a specific level in percent, i.e you need to use that % sign. '''<code>amixer</code>''' understands the percent sign (%), not numbers. If you use a number (say, 90) then '''<code>amixer</code>''' will take it as 100%, which can harm your speakers.<br />
<br />
# amixer set Master 90% unmute<br />
# amixer set PCM 85% unmute<br />
<br />
* Try to play a WAV file<br />
<br />
# aplay /usr/share/sounds/alsa/Front_Center.wav<br />
<br />
'''NOTE:''' Some cards (well, at least Soundblaster Audigy LS) need to have digital output muted/turned off in order to hear analog sound.<br />
<br />
If you cannot hear anything, double check your mixer settings, being sure to unmute PCM, MASTER (and some machines such as the IBM Thinkpad have an additional 'SPEAKER' channel) and try the alsaconf utility as root:<br />
# alsaconf<br />
<br />
* [[Allow multiple programs to play sound at once]]<br />
<br />
==Setup Permissions==<br />
<br />
To be able to use the sound card as a user, follow these steps:<br />
<br />
* Add your user to the audio group:<br />
# gpasswd -a USERNAME audio<br />
<br />
* Log your user out and back in to ensure the audio group is loaded.<br />
<br />
==Restore ALSA Mixer settings at startup==<br />
<br />
* Run 'alsactl' once to create '<code>/etc/asound.state</code>'<br />
<br />
alsactl store<br />
<br />
* Edit '/etc/rc.conf' and add 'alsa' to the list of daemons to start on boot-up. This will store the mixer settings on every shutdown and restore them when you boot.<br />
<br />
* If the mixer settings are not loaded on boot-up, add the following line to '<code>/etc/rc.local</code>'<br />
<br />
alsactl restore<br />
<br />
==Getting SPDIF output==<br />
<br />
(from gralves from the Gentoo forums)<br />
* In GNOME Volume Control, under the Options tab, change the IEC958 to PCM. This option can be enabled in the preferences.<br />
* If you don't have GNOME Volume Control installed,<br />
** Edit /etc/asound.state. This file is where alsasound stores your mixer settings.<br />
** Find a line that says: 'IEC958 Playback Switch'. Near it you will find a line saying value:false. Change it to value:true.<br />
** Now find this line: 'IEC958 Playback AC97-SPSA'. Change its value to 0.<br />
** Restart ALSA.<br />
<br />
Alternative way to enable SPDIF output automatically on login (tested on SoundBlaster Audigy):<br />
* add following lines to /etc/rc.local:<br />
<br />
# Use COAX-digital output<br />
amixer set 'IEC958 Optical' 100 unmute<br />
amixer set 'Audigy Analog/Digital Output Jack' on<br />
<br />
You can see the name of your card's digital output with:<br />
<br />
amixer scontrols<br />
<br />
==KDE Settings==<br />
* Start up KDE:<br />
# startx<br />
<br />
* Set up the volumes as you want them for this user (each user has their own settings):<br />
# alsamixer<br />
<br />
log out and log back in as user xyz to get sound to work (I had to kill x logout then log back in as user xyz, then start x and open firefox and bam audio working on youtube)<br />
<br />
* <b>KDE 3.3</b> Go to K Menu > Multimedia > KMix<br />
** Choose Settings > Configure KMix...<br />
** Uncheck the option "Restore volumes on logon"<br />
** Press OK, and you should be all set. Now your volumes will be the same from the command line or within KDE.<br />
<br />
==System-Wide Equalizer==<br />
Note: This method requires the use of a ladspa plugin which might use quite a bit of cpu when sound plays. In addition, this was made with stereophonic sound (e.g. headphones) in mind.<br />
<br />
* you will need, in addition to the aforementioned userspace utilities, alsa-plugins<br />
pacman -S alsa-plugins<br />
* get the ladspa and swh-plugins packages too if you don't already have them<br />
pacman -S ladspa swh-plugins<br />
* if you haven't already created either an ~/.asoundrc or a /etc/asound.conf file, then create either one<br />
vim ~/.asoundrc<br />
* insert the following into your alsa configuration file (~/.asoundrc or /etc/asound.conf)<br />
pcm.eq {<br />
type ladspa<br><br />
# The output from the EQ can either go direct to a hardware device<br />
# (if you have a hardware mixer, e.g. SBLive/Audigy) or it can go<br />
# to the software mixer shown here.<br />
#slave.pcm "plughw:0,0"<br />
slave.pcm "plug:dmix"<br><br />
# Sometimes you may need to specify the path to the plugins,<br />
# especially if you've just installed them. Once you've logged<br />
# out/restarted this shouldn't be necessary, but if you get errors<br />
# about being unable to find plugins, try uncommenting this.<br />
#path "/usr/lib/ladspa"<br><br />
plugins [<br />
{<br />
label mbeq<br />
id 1197<br />
input {<br />
#this setting is here by example, edit to your own taste<br />
#bands: 50hz, 100hz, 156hz, 220hz, 311hz, 440hz, 622hz, 880hz, 1250hz, 1750hz, 25000hz,<br />
#50000hz, 10000hz, 20000hz<br />
controls [ -5 -5 -5 -5 -5 -10 -20 -15 -10 -10 -10 -10 -10 -3 -2 ]<br />
}<br />
}<br />
]<br />
}<br><br />
# Redirect the default device to go via the EQ - you may want to do<br />
# this last, once you're sure everything is working. Otherwise all<br />
# your audio programs will break/crash if something has gone wrong.<br><br />
pcm.!default {<br />
type plug<br />
slave.pcm "eq"<br />
}<br><br />
# Redirect the OSS emulation through the EQ too (when programs are running through "aoss")<br><br />
pcm.dsp0 {<br />
type plug<br />
slave.pcm "eq"<br />
}<br />
<br />
*reload your alsa settings (as root)<br />
/etc/rc.d/alsa restart<br />
<br />
*you should be good to go (if not, ask in the forum)<br />
<br />
<br />
=Troubleshooting=<br />
==Still Getting No Sound?==<br />
<br />
Remember, ALSA installs with all channels '''muted by default''' (see previous section, [[ALSA#Unmuting_the_channels_and_testing_the_sound_card|unmuting your soundcard]]).<br />
<br />
However, if you're sure nothing is muted, that your drivers are installed correctly, and that your volume is right, but you still do not hear anything, then try blacklisting snd_pcsp from your modules array in rc.conf:<br />
<br />
MODULES=(!snd_pcsp ... )<br />
<br />
Note that this will disable your PC's internal speaker.<br />
If that doesn't work, then try adding the following line to <code>/etc/modprobe.conf</code>:<br />
<br />
options snd-NAME-OF-MODULE ac97_quirk=0<br />
<br />
The above fix has been observed to work with <code>via82xx</code><br />
options snd-NAME-OF-MODULE ac97_quirk=1<br />
The above fix has been reported to work with <code>snd_intel8x0</code><br />
<br />
==No Sound with Onboard Intel Sound Card==<br />
<br />
There may be an issue with two conflicting modules loaded, namely <code>snd_intel8x0</code> and <code>snd_intel8x0m</code>. In this case, edit <code>rc.conf</code> and in the MODULES array blacklist the latter one so that it reads <code>!snd_intel8x0m</code> afterwards.<br />
<br />
''Muting'' the "External Amplifier" in <code>alsamixer</code> or <code>amixer</code> may also help. See [http://alsa.opensrc.org/index.php/Intel8x0#Dell_Inspiron_8600_.28and_probably_others.29 the ALSA wiki].<br />
<br />
==Poor Sound Quality?==<br />
<br />
If you experience poor sound quality, try setting the PCM volume (in alsamixer) to a level such that gain is 0.<br />
<br />
==Pops when Starting and Stopping Playback?==<br />
<br />
Some modules can power off your sound card when not in use. this can make an audible noise when powering down your sound card. If you find this annoying try "modinfo snd-MY-MODULE", and look for a module option that adjusts or disables this feature. <br />
<br />
for example: to disable the power saving mode using snd-hda-intel add "options snd-hda-intel power_save=0" in /etc/modprobe.conf. or try it with "modprobe snd-hda-intel power_save=0"<br />
<br />
==Alsamixer does not run==<br />
If running alsamixer does not work and you wind up with the following error<br />
alsamixer: function snd_ctl_open failed for default: No such device or directory<br />
<br />
You should first check /etc/group to ensure that your current user is in the 'audio' group.<br />
<br />
Then you might need to re-install your kernel. Run 'pacman -S kernel26' or whichever patchset you prefer to use.<br />
<br />
==S/PDIF output does not work==<br />
If the optical/coaxial digital output of your motherboard/sound card is not working or stopped working, and have already enabled and unmuted it in alsamixer, try running<br />
iecset audio on<br />
<br />
as root.<br />
<br />
You can also put this command in rc.local as it sometimes it may stop working after a reboot.<br />
<br />
==No adjustable PCM channel==<br />
You may find that you lack adjustable PCM channel. In this case try to remove all sound-related stuff from MODULES section in /etc/rc.conf, except for snd-NAME-OF-MODULE and snd-pcm-oss.<br />
<br />
== HP TX2500 ==<br />
<br />
Add these 2 lines into /etc/modprobe.conf:<br />
<br />
options snd-cmipci mpu_port=0x330 fm_port=0x388<br />
<br />
options snd-hda-intel index=0 model=toshiba position_fix=1<br />
<br />
And don't forget to enable 'hal' in the DAEMONS section of your /etc/rc.conf<br />
<br />
= External Resources =<br />
More info can be found here<br />
* [http://alsa.opensrc.org/index.php/Main_Page Unofficial ALSA Wiki]<br />
* [http://alsa.opensrc.org/index.php/Aadebug A simple shell script to aid ALSA audio debugging]<br />
* [http://bbs.archlinux.org/viewtopic.php?id=36815 HOWTO: Compile driver from svn]<br />
* [http://gentoo-wiki.com/HOWTO_Set_up_a_system-wide_equaliser_with_ALSA_and_LADSPA HOWTO Set up a system-wide equaliser with ALSA and LADSPA]</div>ColdPiehttps://wiki.archlinux.org/index.php?title=Xorg&diff=42257Xorg2008-05-31T00:33:03Z<p>ColdPie: </p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|Dansk|Xorg (Dansk)}}<br />
{{i18n_entry|English|Xorg}}<br />
{{i18n_entry|Español|Configurando Xorg (Español)}}<br />
{{i18n_entry|Polski|Xorg_(Polski)}}<br />
{{i18n_entry|Русский|Xorg (Русский)}}<br />
{{i18n_entry|Česky|Xorg (Česky)}}<br />
{{i18n_entry|Italiano|Xorg (Italiano)}}<br />
{{i18n_entry|简体中文|Xorg (简体中文)}}<br />
{{i18n_links_end}}<br />
<br />
== Introduction ==<br />
<br />
'''Xorg''' is the public, open-source implementation of the X11 X Window System. (See the [http://en.wikipedia.org/wiki/X.Org_Server X.org Wikipedia Article] or [http://wiki.x.org/wiki/ X.org] for details.) Basically, if you want a GUI atop Arch, you will want xorg.<br />
<br />
==Installing Xorg==<br />
<br />
Before beginning, make sure you do the following:<br />
#Make sure that [[pacman]] is configured and refreshed.<br />
#If you are running another X server you can close it now. <code>ctrl+alt+backspace</code><br />
#Make a note about third-party drivers (e.g., nVidia or ATI drivers). <br />
<br />
First let us install the complete 'xorg' group:<br />
<br />
# pacman -S xorg<br />
<br />
The default 'vesa' driver is merely a fallback (not accelerated and doesn't support many resolutions), so you will need a proper video driver too. You can type this command to list all the video drivers available:<br />
<br />
# pacman -Ss xf86-video<br />
<br />
Look for the appropriate driver for your card and install it with pacman -S. To check your card, if hwd is installed, run 'hwd -s', or run 'lspci' (look for 'VGA compatible controller'). <br />
<br />
If Xorg installed OK, it's time to make <code>xorg.conf</code><br />
<br />
==Configuring xorg==<br />
<br />
Before you can run xorg, you need to configure it so that it knows about your graphics card, monitor, mouse and keyboard. There are several methods of automating the process:<br />
<br />
===hwd===<br />
<br />
Perhaps the easiest way of getting Xorg up and running quickly is to use <tt>hwd</tt>, a tool written by users in the Arch Linux community. It's basically a hardware-detection tool that has multiple uses, one of which is setting up an X server. Fortunately, hwd is much more streamlined than <code>xorgconf</code> and doesn't require any input at all.<br />
<br />
First, install the <tt>hwd</tt> package:<br />
# pacman -S hwd<br />
<br />
Now simply run the following command as root to generate a default <code>xorg.conf</code> file:<br />
# hwd -xa<br />
<br />
This will overwrite any existing /etc/X11/xorg.conf file with a practical set of defaults, based on what <tt>hwd</tt> detected for your hardware.<br />
<br />
Alternatively, you can generate a sample Xorg config (/etc/X11/xorg.conf.hwd) without overwriting your existing settings. To do so, run <tt>hwd</tt> with the '''-x''' flag instead:<br />
# hwd -x<br />
<br />
Sample result:<br />
/etc/X11/xorg.conf.ati<br />
/etc/X11/xorg.conf.vesa<br />
<br />
Your sample file(s) ready, rename 'xorg.conf'.<br />
If unsure first try 'vesa' (default).<br />
<br />
To use the sample config(s), you must manually rename it. Sample:<br />
# mv /etc/X11/xorg.conf.vesa /etc/X11/xorg.conf<br />
<br />
AD: In my experience hwd creates XF86Config-4 file and if there is not xorg.conf present Xorg uses it automatically.<br />
<br />
===xorgconfig===<br />
<br />
To start up <tt>xorgconfig</tt>:<br />
<br />
# xorgconfig<br />
<br />
or<br />
<br />
# xorgcfg -textmode<br />
<br />
These will generate a new <tt>xorg.conf</tt>.<br />
<br />
Answer the questions, and the program will make the file for you.<br />
This program is not really good but it's a start, and you can fill in special stuff manually afterwards.<br />
<br />
===Xorg -configure===<br />
You can also use<br />
# Xorg -configure<br />
or<br />
# X -configure<br />
<br />
===nvidia-xconfig===<br />
nVidia users can also use<br />
# nvidia-xconfig<br />
when they have official nvidia drivers [[NVIDIA|installed]].<br />
<br />
Comment the line<br />
<br />
Load "type1"<br />
<br />
in the Module section since recent versions of xorg-server does not include the type1 font module (completely replaced by freetype).<br />
<br />
==Editing xorg.conf==<br />
<br />
You may wish to edit the config after it's been generated. To open in your favourite text-editor, such as Vim (you need root privileges):<br />
<br />
# vim /etc/X11/xorg.conf<br />
<br />
or use Xorg Configuration toolkit:<br />
<br />
# xorgcfg -textmode<br />
<br />
If you want to set up mouse wheel support, see [[Get All Mouse Buttons Working]].<br />
<br />
===Monitor Settings===<br />
<br />
Depending on your hardware, Xorg may fail to detect your monitor capabilities correctly, or you may simply wish to use a lower resolution than your monitor is capable of. You might want to look up the following values in your monitor's manual before setting them.<br />
The following settings are specified in the Monitor section:<br />
<br />
====Horizontal Sync====<br />
<br />
HorizSync 28-64<br />
<br />
====Refresh Rate====<br />
<br />
VertRefresh 60<br />
<br />
The following are specified in the Screen section:<br />
<br />
====Colour Depth====<br />
<br />
Depth 24<br />
<br />
====Resolution====<br />
<br />
Modes "1280x1024" "1024x768" "800x600"<br />
<br />
=== Keyboard Settings ===<br />
<br />
Xorg may fail to detect your keyboard correctly. This might give problems with your keyboard layout or keyboard model not being set correctly.<br />
<br />
To see a full list of keyboard models, layouts, variants and options, open.<br />
<br />
<br />
/usr/share/X11/xkb/rules/xorg.lst<br />
<br />
==== Keyboard Layout ====<br />
<br />
To change the keyboard layout, use the XkbLayout option in the keyboard InputDevice section. For example, if you have a keyboard with English layout:<br />
<br />
Option "XkbLayout" "gb"<br />
<br />
To be able to easily switch keyboard layouts, for example between a US and a Swedish layout use this instead:<br />
<br />
Option "XkbLayout" "us, se"<br />
Option "XkbOptions" "grp:caps_toggle"<br />
<br />
This makes your Caps Lock key switch between the different layouts. This is mainly useful if you run don't run a Desktop Environment which takes care of keyboard layouts for you.<br />
<br />
==== Keyboard Model ====<br />
<br />
To change the keyboard model, use the XkbModel option in the keyboard <br />
InputDevice section. For example, if you have a Microsoft Wireless Multimedia Keyboard:<br />
<br />
Option "XkbModel" "microsoftmult"<br />
<br />
===Display Size/DPI===<br />
<br />
In order to get correct sizing for fonts the display size must be set for your desired DPI. In the section <code>"Monitor"</code> put in your display size in mm:<br />
<br />
Section "Monitor"<br />
...<br />
DisplaySize 336 252 # 96 DPI @ 1280x960<br />
...<br />
EndSection<br />
<br />
<br />
The formula for calculating the DisplaySize values is Width x 25.4 / DPI and Height x 25.4 / DPI. If you're running Xorg with a resolution of 1024x768 and want a DPI of 96, use 1024 x 25.4 / 96 and 768 x 25.4 / 96. Round numbers down.<br />
<br />
# calc: (x|y)pixels * 25.4 / dpi<br />
# DisplaySize 168 126 # 96 DPI @ 640x480<br />
# DisplaySize 210 157 # 96 DPI @ 800x600<br />
# DisplaySize 269 201 # 96 DPI @ 1024x768<br />
# DisplaySize 302 227 # 96 DPI @ 1152x864<br />
# DisplaySize 336 252 # 96 DPI @ 1280x960<br />
# DisplaySize 336 210 # 96 DPI @ 1280x800 (non 4:3 aspect)<br />
# DisplaySize 339 271 # 96 DPI @ 1280x1024 (non 4:3 aspect)<br />
# DisplaySize 370 277 # 96 DPI @ 1400x1050<br />
# DisplaySize 420 315 # 96 DPI @ 1600x1200<br />
# DisplaySize 444 277 # 96 DPI @ 1680x1050<br />
# DisplaySize 506 315 # 96 DPI @ 1920x1200 (non 4:3 aspect)<br />
<br />
<br />
For nVidia drivers you may have to disable automatic detection of DPI to set it manually. There is also an easier way to set DPI on these cards. Either or both of the following lines can be set in the device section for your nVidia card.<br />
<br />
Option "UseEdidDpi" "false"<br />
Option "DPI" "96 x 96"<br />
<br />
<br />
Results can be checked by issuing the following command, which should return 96x96 dots per inch if you set DPI @ 96.<br />
<br />
$ xdpyinfo | grep -B1 dot<br />
<br />
===Proprietary Drivers===<br />
<br />
If you wish to use third-party graphics drivers, do check first that the X server runs OK first. Xorg should run smoothly without official drivers, which are typically needed only for advanced features such as 3D-accelerated rendering for games, dual-screen setups, and TV-out. Refer to the [[NVIDIA]] and [[ATI]] wikis for help with driver installation.<br />
<br />
===Fonts===<br />
<br />
There some tips for setting up fonts in [[Xorg Font Configuration]].<br />
<br />
=== Sample Xorg.conf Files ===<br />
Anyone who has an Xorg.conf file written up that works, go ahead and post a link to it here for others to look at! Please don't inline the entire conf file; upload it somewhere else and link. Thanks!<br />
* Shadowhand (nv and nvidia drivers): http://people.os-zen.net/shadowhand/configs/xorg.conf<br />
* Cerebral (fglrx and radeon drivers): http://www.student.cs.uwaterloo.ca/~tjwillar/configs/xorg.conf<br />
* raskolnikov (via unichrome and synaptics drivers): http://athanatos.free.fr/Arch/xorg.conf<br />
* Leigh (Three independent screens - Three nvidia cards): http://files.myopera.com/allisonleigh/linuxbackup/xorg.conf<br />
* Mr.Elendig (nvidia with composite and "stuff") http://arch.har-ikkje.net/stuff/xorg.conf<br />
<br />
==Running Xorg==<br />
<br />
This is done simply by typing:<br />
<br />
$ startx<br />
<br />
The default X environment is rather bare, and you will typically seek to install window managers or desktop environments to supplement X. <br />
<br />
To test the config file you have created:<br />
<br />
$ X -config ''<your config file>''<br />
<br />
If a problem occurs, then view the log at <tt>/var/log/Xorg.0.log</tt>. Be on the lookout for any lines beginning with ''(EE)'' which represent errors, and also ''(WW)'' which are warnings that could indicate other issues.<br />
<br />
'''*Please Note*'''<br />
Using startx requires a ''~/.xinitrc'' file, so that X knows what to run when it starts. Your best option is to copy ''/etc/skel/.xinitrc'' to your home directory and edit it. Comment out the 'exec' lines you don't want, and add or uncomment one for the WM you want to use. If you are using GNOME it is best to start GNOME through gdm to avoid HAL permission problems.<br />
<br />
In addition, you can also install twm and xterm (via pacman), which will be used as a fallback if ~/.xinitrc does not exist (as stated in /etc/X11/xinit/xinitrc).<br />
<br />
==X startup (/usr/bin/startx) tweaking==<br />
For X's option reference see<br />
<br />
$ man Xserver<br />
<br />
The following options have to be appended to the variable "defaultserverargs" in the /usr/bin/startx file.<br />
<br />
prevent X from listening on tcp:<br />
-nolisten tcp<br />
getting rid of the gray weave pattern while X is starting and let X set a black root window:<br><br />
-br<br />
enable deferred glyph loading for 16 bit fonts:<br />
-deferglyphs 16<br />
<br />
Note: If you start X with kdm, the startx script does not seem to be executed. X options must be appended to the variable "ServerCmd" in the /opt/kde/share/config/kdm/kdmrc file. By default kdm options are<br />
<br />
ServerCmd=/usr/bin/X -br -nolisten tcp<br />
<br />
== Changes with modular Xorg ==<br />
<br />
=== Most Common Packages ===<br />
<br />
Make sure you install drivers for mouse, keyboard and videocard. For mouse and keyboard, '''xf86-input-keyboard''' and '''xf86-input-mouse''' should get installed. Other '''xf86-input-*''' packages are available for different input devices.<br />
<br />
For the videocard, find out which driver is required and install the right '''xf86-video-*''' package. ATI and Nvidia users may wish to install the non-free drivers for their hardware instead ([[NVIDIA]], [[ATI]]).<br />
<br />
To install all drivers in one run, the '''xorg-input-drivers''' and '''xorg-video-drivers''' are available.<br />
<br />
=== OpenGL 3D Acceleration ===<br />
<br />
X.Org 7.0 on Arch Linux uses a modular design for mesa, the OpenGL rendering system. Several implementations are available:<br />
* libgl-dri: Open-source DRI OpenGL implementation. Falls back to software rendering when no DRI driver is installed<br />
* some other driver providing libGL (ati, nvidia)<br />
<br />
When pacman installs an application that needs mesa, it will install one of these packages. To be sure about the right library for your setup, install the library you want prior to installing Xorg. Installing the right package afterwards is also possible, though this gives some dependency errors sometimes, which can be ignored with the -d switch.<br />
<br />
=== Glxgears and Glxinfo ===<br />
<br />
These apps are included in the mesa package.<br />
<br />
=== Changed paths (and configuration) ===<br />
<br />
'''See this entry for additional upgrade info:''' http://www.archlinux.org/blog/2006/01/02/how-to-upgrade-xorg/<br />
<br />
Modular X.Org 7 installs everything in <code>/usr</code>, where the older versions installed in <code>/usr/X11R6</code>. Several configuration files need updates:<br />
* ''/etc/X11/xorg.conf''<br />
** Fontpaths live in /usr/share/fonts now<br />
** RGB database is in /usr/share/X11/rgb<br />
** module path is /usr/lib/xorg/modules<br />
<br />
Also note that some X configuration tools might stop working. The easiest way to configure X.org is by installing the correct driver packages and running ''Xorg -configure'', which results in a <code>/root/xorg.conf.new</code> which only needs modification in the resolutions, mouse configuration and keyboard layouts.<br />
<br />
Some packages have hard-coded references to <code>/usr/X11R6</code>. These packages need fixing. In the meantime, look what packages install files in <code>/usr/X11R6</code>, uninstall those, make a symlink from <code>/usr</code> to <code>/usr/X11R6</code> and reinstall the affected packages. Another option is to move the contents of <code>/usr/X11R6</code> to <code>/usr</code> and make the symlink.<br />
<br />
Or you can just add a second module path via <code/>ModulePath "/usr/X11R6/lib/modules"</code> <br />
This works e.g. for Nvidia 76.76<br />
<br />
== Troubleshooting ==<br />
<br />
=== Xorg "can't see" the resolutions your monitor supports ===<br />
I found myself in a situation where if i used one of my monitors(a gnr ts902) Xorg would only present me with the options 640x480 and 320x480 which ofcourse was less than i desired. After a lot of research i found through read-edid(in aur) that part of my EDID was corrupt and so i could only read my HorizSync with read-edid. This fortunately was enough and after adding the right Horisync line to the xorg.conf's Monitor section(didn't have to add VertRefresh...) I restarted X to see the right resolution :)<br />
<br />
note: I'm not sure:<br />
<br />
Option "ModeValidation" "NoEdidModes"<br />
Option "UseEdid" "false"<br />
<br />
in Device section in xorg config are needed aswell, to lazy now to test without them :)<br />
<br />
=== Keyboard Problems ===<br />
<br />
Auto-generated xorg.conf files may cause you problems. If you cannot get to tty1 by holding CTRL-ALT and pressing F1 or cannot get the £ sign for gb people, check to see if the following entries are in your /etc/X11/xorg.conf:<br />
<br />
Option "XkbLayout" "uk" #"uk" is not a real layout, look in /usr/share/X11/xkb/symbols/ for a list of real ones.<br />
Option "XkbRules" "xfree86" #this should be "xorg"<br />
Option "XkbVariant" "nodeadkeys" #This line is also known to cause the problems described, try commenting it out.<br />
<br />
To switch between layouts with Alt+Shift:<br />
Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll"<br />
<br />
===A Quick Fix for the Bitstream-Vera Conflict===<br />
If you see a message that ttf-bitstream-vera conflicts with xorg:<br />
#Exit the pacman session by answering no.<br />
#Run <code>pacman -Rd xorg</code><br />
#Run <code>pacman -Syu</code><br />
#Run <code>pacman -S xorg</code><br />
#Update your paths in /etc/X11/xorg.conf<br />
<br />
===A Quick Fix for file conflicts in /usr/include===<br />
If you see messages about file conflicts in /usr/include/X11 and /usr/include/GL:<br />
#Run <code>rm /usr/include/{GL,X11}</code><br />
#Run <code>pacman -Su</code><br />
The symlinked directories removed by this operation are replaced by real directories in the new xorg package, causing these file conflicts to appear.<br />
<br />
=== libgl-dri conflicts ===<br />
<br />
If you get a message similar to:<br />
:: libgl-dri conflicts with nvidia-legacy. Remove nvidia-legacy? [Y/n]<br />
this is due to the multiple OpenGL implementations explained in the OpenGL section above - pacman is attempting to install libgl-dri to satisfy this dependency, but also trying to upgrade your existing video driver, and they conflict. To solve, try:<br />
<br />
* Updating your video driver before a full system update: <br />
# pacman -S nvidia-legacy<br />
# pacman -Syu<br />
<br />
Or, if that doesn't work,<br />
* Remove your existing video driver, do the update, then reinstall your driver:<br />
# pacman -Rd nvidia-legacy<br />
# pacman -Syu<br />
# pacman -S nvidia-legacy<br />
:: nvidia-legacy conflicts with libgl-dri. Remove libgl-dri? [Y/n] '''Y'''<br />
<br />
=== Mouse wheel not working ===<br />
The "Auto" protocol doesn't seem to work properly in Xorg 7 any more. In the InputDevice section for your mouse, change:<br />
Option "Protocol" "auto"<br />
to<br />
Option "Protocol" "IMPS/2"<br />
or<br />
Option "Protocol" "ExplorerPS/2"<br />
<br />
=== Extra mouse buttons not working ===<br />
USB Mice users should read [[Get_All_Mouse_Buttons_Working]].<br />
<br />
Intellimouse (ExplorerPS/2) users might find their scroll and side buttons aren't behaving as they used to. Previously xorg.conf needed:<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "6 7"<br />
and users also had to run xmodmap to get the side buttons working with a command like:<br />
xmodmap -e "pointer = 1 2 3 6 7 4 5"<br />
Now xmodmap is no longer required. Instead, make xorg.conf look like this:<br />
Option "Buttons" "5"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 6 7"<br />
and the side buttons on a 7-button Intellimouse will work like they used to, without needing to run xmodmap.<br />
<br />
===Keyboard problems===<br />
Some keyboard layouts have changed. I wondered why:<br />
* I wasn't able to Ctrl+Alt+Fx to switch to console<br />
* I wasn't able to use layouts<br />
The problem was that the ''sk_qwerty'' layout doesn't exist anymore. I had to replace<br />
Option "XkbLayout" "us,sk_qwerty"<br />
with<br />
Option "XkbLayout" "us,sk"<br />
Option "XkbVariant" ",qwerty"<br />
<br />
Another thing to look for if your keyboard isn't properly functioning is the XkbRules option:<br><br />
You'll need to change<br />
Option "XkbRules" "xfree86"<br />
to<br />
Option "XkbRules" "xorg"<br />
<br />
==== AltGR (Compose Key) not working properly ====<br />
<br />
If, after the update, you can't use the AltGr key as expected any more, try adding this to your keyboard section:<br />
Option "XkbOptions" "compose:ralt"<br />
<br />
This is not the correct way to activate the AltGr Key on a German keyboard (for example, to use the '|' and '@' keys on German keyboards).<br />
Just choose a valid keyboard variant for it to work again, for example (the example is for a German keyboard):<br />
Option "XkbLayout" "de"<br />
Option "XkbVariant" "nodeadkeys"<br />
<br />
The solutions above don't work on an Italian keyboard. To activate the AltGr key on an Italian keyboard make sure you have the following lines set up properly:<br />
Driver "kbd"<br />
Option "XkbRules" "xorg"<br />
Option "XkbVariant" ""<br />
<br />
This might still not be enough for a swedish keyboard. Try the above, but with lv3 instead of compose. (Thank you wyvern!)<br />
That is:<br />
Option "XkbLayout" "se"<br />
Option "XkbVariant" "nodeadkeys"<br />
Option "XkbOptions" "lv3:ralt_switch"<br />
<br />
==== Can't set qwerty layouts using the setxkbmap command ====<br />
<br />
After the update, there aren't qwerty layouts as for example sk_qwerty. If you want to switch your present keyboard layout to any qwerty keyboard layout use this command:<br />
$ setxkbmap NAME_OF_THE_LAYOUT qwerty<br />
e.g.: for sk_qwerty use:<br />
$ setxkbmap sk qwerty<br />
<br />
After the update, trying the above command I had this message "Error loading new keyboard description".<br />
I find out that the xserver doesn't have the rights to write, execute, read in the directory /var/tmp<br />
So give the permissions to that directory. Restart the xserver and you will have your deadkeys back!<br />
Don't believe? Try out the code e.g.: it layout<br />
$ setxkbmap -layout it<br />
<br />
==== Setup French Canadian (old ca_enhanced) layout ====<br />
<br />
With Xorg7, "ca_enhanced" is no more. You have to do a little trick to get the same layout that you are used to:<br />
Switch the old:<br />
Option "XkbLayout" "ca_enhanced"<br />
To:<br />
Option "XkbLayout" "ca"<br />
Option "XkbVariant" "fr"<br />
<br />
It will be similar with other layout, I presume. You can refer to Gentoo HowTo there: http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml<br />
<br />
<br />
<br />
=== Missing libraries ===<br />
* '''Help! I get an error message running my favourite app saying "libXsomething" doesn't exist!'''<br><br />
In most cases, all you need to do is take the name of the library (eg libXau.so.1), convert it all to lowercase, remove the extension, and pacman for it:<br />
# pacman -S libxau<br />
<br />
This will install the library you're missing, and all will be well again!<br />
<br />
=== Some packages fail to build and complain about missing X11 includes ===<br />
<br />
Just reinstall the packages xproto and libx11, even if they are already installed.<br />
<br />
=== Unable to load font '(null)' ===<br />
* '''Some programs don't work and say unable to load font `(null)'.'''<br><br />
These packages would like some extra fonts. Some programs only work with bitmap fonts.<br />
Two major packages with bitmap fonts are available, xorg-fonts-75dpi and xorg-fonts-100dpi. You don't need both; one should be enough. To find out which one would be better in your case, try this:<br />
<br />
$ xdpyinfo | grep resolution<br />
<br />
and grab what is closer to you (75 or 100 instead of XX)<br />
<br />
# pacman -S xorg-fonts-XXdpi<br />
<br />
=== KDE Taskbar/Desktop Icons Broken ===<br />
* '''KDE taskbar doesn't work and the desktop icons disappear'''<br><br />
Install the packages libxcomposite and libxss. It will be fine.<br />
<br />
# pacman -S libxcomposite libxss<br />
<br />
=== Updating from testing version to extra (missing files) ===<br />
<br />
If you've updated from Xorg 7 in testing to Xorg 7 in extra and are finding that many files seem to be missing (including startx, /usr/share/X11/rgb.txt, and others), you may have lost many files due to the xorg-clients package splitting from a single package into many smaller sub packages. <br><br />
<br />
You need to reinstall all the packages that are dependencies of xorg-clients:<br />
# pacman -S xorg-apps xorg-font-utils xorg-res-utils xorg-server-utils \<br />
xorg-twm xorg-utils xorg-xauth xorg-xdm xorg-xfs xorg-xfwp \<br />
xorg-xinit xorg-xkb-utils xorg-xsm<br />
<br />
This should fix the problem.<br />
<br />
=== Problem with MIME types in various desktop environments ===<br />
<br />
If you noticed icons missing and can't click-open files in desktop environments, add the following lines to /etc/profile or your preferred init script and reboot.<br />
XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/share<br />
export XDG_DATA_DIRS<br />
<br />
=== DRI stops working with Matrox cards ===<br />
<br />
If you use a Matrox card and DRI stops working after upgrading to xorg7, try adding the line<br />
Option "OldDmaInit" "On"<br />
to the Device section that references the video card in xorg.conf.<br />
<br />
=== Cannot start any clients under Xephyr ===<br />
<br />
The client connections are rejected by the X server's security mechanism, you can find a complete explanation and solution in [http://wiki.debian.org/XStrikeForce/FAQ#howtoxnest].<br />
<br />
=== Cannot start X clients as root using "su" ===<br />
<br />
If you're getting "Client is not authorized to connect to server", try adding the line <br />
<br />
session optional pam_xauth.so<br />
<br />
to the file /etc/pam.d/su. <br />
pam_xauth will properly set environment variables and handle xauth keys.<br />
<br />
== Links ==<br />
See also:<br />
<br />
* [[Enabling a DM]]<br />
* [[Start X at boot]]<br />
* [[Xorg Font Configuration]]<br />
* Proprietary Video Drivers<br />
** [[ATI]]<br />
** [[NVIDIA]]<br />
* [[Desktop Environment]]<br />
** [[KDE]]<br />
** [[GNOME]]<br />
** [[Xfce]]<br />
** [[Enlightenment]]<br />
** [[Fluxbox]]<br />
** [[Openbox]]<br />
== External Links ==<br />
<br />
* [http://en.wikipedia.org/wiki/X.Org_Server X.org Wikipedia Article]<br />
* [http://wiki.x.org/wiki/ X.org]<br />
* [http://archux.com/page/installing-and-setting-xorg Installing and setting up Xorg]</div>ColdPie