Difference between revisions of "Talk:GRUB"

From ArchWiki
Jump to: navigation, search
(Possible mistake?)
(I removed unnecessary indentation and added clarification to promote discussion and content improvements.)
 
(227 intermediate revisions by 32 users not shown)
Line 1: Line 1:
== GRUB Legacy stuff should be removed ==
+
== Alpha sorting for kernel names without versions ==
  
I mean, seriously, the page is loaded with too much information anyway. And also because of this: http://www.archlinux.org/news/grub-legacy-no-longer-supported/ --[[User:DSpider|DSpider]] ([[User talk:DSpider|talk]]) 17:41, 29 August 2012 (UTC)
+
When installing the "linux" and "linux-lts" kernels on a basic install, the ''/etc/grub.d/10_linux'' in 2.02-beta1 will try and use a numeric-oriented sorting routine that doesn't work well for kernels without any versions in the names of the files. I've submitted a feature request and patch for this upstream:
  
== EFI ==
+
* https://savannah.gnu.org/bugs/index.php?42597
  
Is there any reason why grub should be installed to /boot/efi/efi/grub and not to /boot/efi? UEFI wants to have the efi-image unter <EFI SYSTEM PARTITION>/efi/name, so /boot/efi/grub should do the trick.
+
Forum discussion w/patch:
Additionally, mounting (e.g.) /dev/sda1 to /boot/efi and just placing the grub there will possibly conflict with having a LVM+LUKS setup, where /boot will then be encrypted. At the moment I'm running a funtoo installation on a thinkpad x121e with /dev/sda1 (200MB, fat32, sectors 1 - 201) mounted to /boot and /dev/sda2 being a LUKS encrypted system. /boot contains the bzImage and /boot/efi/boot/bootx64.efi is the grub-image.
 
  
Note: there should possibly be a section/table here containing information what firmware expects what name. having /boot/efi/grub/grub.efi didn't work for me, and as noted in the thinkwiki for an x220, /boot/efi/boot/bootx64.efi works fine. --[[User:Rochus|Rochus]] 13:59, 16 August 2011 (EDT)
+
* https://bbs.archlinux.org/viewtopic.php?pid=1428523
  
 +
: [//gist.github.com/fstirlitz/7639129 I solved this (and other problems) long ago…] why nobody applied this patch to the Arch package is beyond me. [[User:Fstirlitz|felix]] ([[User talk:Fstirlitz|talk]]) 14:11, 8 August 2014 (UTC)
  
@Rochus: You have mounted your EFISYS partition at /boot ir you are using same part as both EFISYS and /boot and it is FAT32 formatted. The actual path is <EFI_SYS_PART>/efi/grub/grub.efi wherein <EFI_SYS_PART> is usually /boot/efi or in your case /boot itself.
+
::What is the current sate of this issue? --[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 10:56, 6 December 2014 (UTC)
  
But I do not understand your argument about mounting EFISYS at /boot/efi conflicting with LVM+LUKS. I don't have such a config in my system to understand what you are coming to say. <EFI_SYS_PART>/efi/boot/bootx64.efi is just a fallback path incase there's no boot entry in UEFI Boot Manager (see efibootmgr section). I already mentioned in the article that "If you have mounted EFISYS part at a different mountpoint, replace /boot/efi with that mountpoint in all the commands". I suppose that explains it. It is better to have /boot separate from EFISYS partition. I have /dev/sda1 as 200 MiB FAT32 EFISYS mounted at /boot/efi and /dev/sda3 as 400 MiB ext4 /boot part. For /boot/efi/grub/grub.efi to work you have to add a boot entry to grub.efi in the UEFI Boot Manager using efibootmgr utility. -- [[User:the.ridikulus.rat|Keshav P R]] 23:15, 28 August 2011 (IST)
+
:::I'd leave this open right now, as it seems a candidate for merging with [[GRUB/Tips and tricks#Multiple entries]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 19:36, 22 December 2014 (UTC)
  
== GRUB_GFXMODE may not work with a depth parameter ==
+
== Manually generate grub.cfg ==
  
I'm installing on an i5 system with Intel graphics, and found that I could not get a background image if I used any depth parameter in GRUB_GFXMODE=; if I used the 0x value I got the same errors. I would get a black screen with a blue box, titled "Out of Range" and some H. Frequency and V. Frequency parameters. The boot continued in the background, and eventually I got the normal scroll of information during the boot. What I found was that if I just used a resolution, e.g., 800x600, with nothing more, it worked fine. Not sure if this is something for the wiki here or elsewhere, or something to post in the forums; but it should be somewhere to save the next person the hassle of figuring it out, I think. -- [[User:Timm|Timm]] 13:08, 29 October 2011 (EDT)
+
In previous revisions, instructions on manually creating a grub.cfg were removed [https://wiki.archlinux.org/index.php?title=GRUB&diff=347960&oldid=347954], and later added to [[GRUB/Tips and tricks]] [https://wiki.archlinux.org/index.php?title=GRUB/Tips_and_tricks&oldid=349645#Manually_creating_grub.cfg]. This was discussed with [https://wiki.archlinux.org/index.php?title=Talk:GRUB&diff=349659&oldid=349657].
 +
However, as it turns out manually creating a grub.cfg is in fact ''encouraged'' upstream [https://www.gnu.org/software/grub/manual/html_node/Simple-configuration.html#Simple-configuration]. This is especially true in Arch as we don't have versioned kernels: {{Bug|16702}} (and thus no changing vmlinuz/initrd paths). As such I believe we should reduce the role of grub-mkconfig, expand on grub.cfg and move it back to the main article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:24, 27 June 2015 (UTC)
 +
: I don't see a problem with this.
 +
: From upstream: '' In the meantime, those who feel that it would be easier to write grub.cfg directly are encouraged to do so... and to '''disable any system provided by their distribution to automatically run grub-mkconfig.'''''
 +
: Correct me if I'm wrong here but I don't think we have anything that automatically calls grub-mkconfig. Therefore manually creating/editing grub.cfg shouldn't be a problem. -- [[User:Chazza|Chazza]] ([[User talk:Chazza|talk]]) 15:01, 27 June 2015 (UTC)
 +
 
 +
::+1, this will also avoid random notes [https://wiki.archlinux.org/index.php?title=Multiboot_USB_drive&diff=379818&oldid=379749 like this] in other articles. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 27 June 2015 (UTC)
 +
 
 +
::Nothing calls grub-mkconfig, no. Yet, I tend to disagree. Reasons: (1) the article is still too long anyway and the fresh start on manually creating grub.cfg is a good base to expand in tips&tricks. (2) Reducing grub-mkconfig basically also means having to touch most content that covers the main options in /etc/default/grub. If I see it right, the Arch package comes with defaults there. (3) Thankfully grub-mkconfig automatically figures menu entry names, but also determines a root= UUID by default these days. The latter not a big problem for simple roots, but cumbersome to describe for others (e.g. when a device mapper is used, lvm, luks, ...). Likewise, grub-mkconfig also uses output from {{Pkg|os-prober}} to automatically generate entries.
 +
::So, I don't think it is a straight-forward task and make things clearer. The instances one would save on "Now re-generate the configuration: ..." would probably have to be replaced with "Now better check the result with grub-script-check /boot/grub/grub.cfg" ... I think it would be better to give [[GRUB/Tips and tricks#Manually creating grub.cfg]] more prominence and expand the fresh base there as required/wanted. Also some of the lengthy menu entry examples of [[GRUB#Automatically generating using .2Fetc.2Fgrub.d.2F40 custom and grub-mkconfig]] could be moved to a section there; they basically work/serve as examples for both (copy pasting into /etc/grub.d/40_custom or /boot/grub/grub.cfg). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:51, 27 June 2015 (UTC)
 +
 
 +
:::I agree with [[User:Indigo|Indigo]]. -- [[User:6arms1leg|6arms1leg]] ([[User talk:6arms1leg|talk]]) 12:48, 28 June 2015 (UTC)
 +
 
 +
::About (1), the inclusion on manually generating grub.cfg would be accompanied by (another, but needed) rewrite of the GRUB article. On (2), similar argument as in (1), and things like modules can be expanded on where needed. (3) It's not because you're not using grub-mkconfig, that you won't use tools such as ''grub-probe'' and ''grub-script-check'' to facilitate some tasks.
 +
::As to clarity, most people just run "grub-mkconfig" without understanding the process at hand, and as such, have difficulties when problems arise.
 +
::Note: I won't have much time to work on this (besides other tasks, I'd prefer to create [[fdisk]] first). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 15:48, 28 July 2015 (UTC)
  
 
== Custom keyboard layout ==
 
== Custom keyboard layout ==
 +
 
Hi. Could we add a section explaining how you can set your preferred keyboard layout within GRUB2? As i found [http://lists.gnu.org/archive/html/grub-devel/2011-06/msg00008.html here], we need the ckbcomp script, which can be obtained from Debian console-setup package.
 
Hi. Could we add a section explaining how you can set your preferred keyboard layout within GRUB2? As i found [http://lists.gnu.org/archive/html/grub-devel/2011-06/msg00008.html here], we need the ckbcomp script, which can be obtained from Debian console-setup package.
  
 
Here's how I made things work:
 
Here's how I made things work:
  
  ckbcomp it | grub-mklayout -o /boot/grub/it.gkb
+
sudo mkdir /boot/grub/layouts
 +
  ckbcomp it |sudo grub-mklayout -o /boot/grub/layouts/it.gkb
  
 
Then, I manually edited {{ic|/boot/grub/grub.cfg}}, adding the following lines:
 
Then, I manually edited {{ic|/boot/grub/grub.cfg}}, adding the following lines:
Line 31: Line 48:
 
<nowiki>
 
<nowiki>
 
terminal_input at_keyboard
 
terminal_input at_keyboard
keymap (hd0,2)/boot/grub/it.gkb
+
keymap it
 
</nowiki>}}
 
</nowiki>}}
  
Line 38: Line 55:
 
Cheers. --[[User:Hilinus|Hilinus]] 12:50, 26 December 2011 (EST)
 
Cheers. --[[User:Hilinus|Hilinus]] 12:50, 26 December 2011 (EST)
  
 
+
:I followed [http://lists.gnu.org/archive/html/grub-devel/2011-03/msg00051.html instructions] on the grub-devel mailing list. First you insert  
 
 
I followed [http://lists.gnu.org/archive/html/grub-devel/2011-03/msg00051.html instructions] on the grub-devel mailing list. First you insert  
 
  
 
{{hc|/etc/default/grub|
 
{{hc|/etc/default/grub|
Line 47: Line 62:
 
</nowiki>}}
 
</nowiki>}}
  
in {{ic|/etc/default/grub}}. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)
+
:in {{ic|/etc/default/grub}}. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)
  
$ ckbcomp si | grub-mklayout -o si.gkb
+
:{{bc|<nowiki>
Unknown key KP_Comma
+
$ ckbcomp si | grub-mklayout -o si.gkb
Unknown key KP_Comma
+
Unknown key KP_Comma
Unknown key KP_Comma
+
Unknown key KP_Comma
Unknown key KP_Comma
+
Unknown key KP_Comma
Unknown keycode 0x79
+
Unknown key KP_Comma
$ sudo mv si.gkb /boot/grub/
+
Unknown keycode 0x79
 +
$ sudo mv si.gkb /boot/grub/
 +
</nowiki>}}
  
After that you add  
+
:After that you add  
  
 
{{hc|/etc/grub.d/40_custom|
 
{{hc|/etc/grub.d/40_custom|
Line 65: Line 82:
 
</nowiki>}}
 
</nowiki>}}
  
to {{ic|/etc/grub.d/40_custom}} and finally generate new grub.cfg with
+
:to {{ic|/etc/grub.d/40_custom}} and finally generate new grub.cfg with
 +
 
 +
:{{bc|$ sudo grub-mkconfig -o /boot/grub/grub.cfg}}
 +
 
 +
:Cheers. --[[User:drevo|drevo]] 17:47, 6 January 2012 (EST)
 +
 
 +
::The version  of ckbcomp I got from Debian Squeeze kept giving this error:
 +
 
 +
::{{bc|Unknown name $sun_t6_custom}}
 +
 
 +
::The Ubuntu Precise version worked out of the box.
 +
 
 +
::A temporary solution for layouts would be an AUR package for ckbcomp or to distribute .gkb files somehow, but the proper solution would be for grub-mklayout to accept keymaps(5) files.
 +
 
 +
::--[[User:Schizius|Schizius]] ([[User talk:Schizius|talk]]) 18:44, 26 July 2012 (UTC)
 +
 
 +
:::This won't work if /boot is on another root partition. At home / is on lvm and /boot on standard MBR partition. This was historical. But since grub.cfg is generated with the root partition in lvm, it can't find my keyboard layout.
 +
:::The clean solution is to create a new file ''/etc/grub.d/50_keymap''and put this:
 +
 
 +
:::{{bc|<nowiki>
 +
#!/bin/sh
 +
set -e
 +
# Include the GRUB helper library for grub-mkconfig.
 +
. /usr/share/grub/grub-mkconfig_lib
 +
KEYMAP_FILE=/boot/grub/bepo.gkb
 +
if ! prepare_grub_to_access_device "`${grub_probe} --target=device "${KEYMAP_FILE}"`"; then
 +
return 6--~~~~
 +
fi
 +
KEYMAP_FILE=$(make_system_path_relative_to_its_root "${KEYMAP_FILE}")
 +
cat <<EOF
 +
insmod keylayouts
 +
keymap "${KEYMAP_FILE}"
 +
EOF
 +
</nowiki>}}
 +
 
 +
:::So that the root partition is detected, loaded, and then the file is read within that partition.
 +
 
 +
:::--[[User:Glandos|Glandos]] ([[User talk:Glandos|talk]]) 08:23, 14 November 2013 (UTC)
 +
 
 +
::::Is Glandos's solution to be used in addition to the Perl script, or is it a standalone solution? I get the vague sense that it is to be used as an additional step only when your /boot is located in its own partition. If someone can clarify this, I will add the above steps to the wiki and test them out, because I was looking for a solution to this same issue. [[User:Ingengnue|ingegnue]] ([[User talk:Ingengnue|talk]]) 09:39, 5 October 2014 (UTC)
  
$ sudo grub-mkconfig -o /boot/grub/grub.cfg
+
::::::There is a discussion further down the page about restructuring and cleaning up the GRUB article. I will make a suggestion to add a section like this in that discussion. This way we can see how much demand there is for it and get suggestions about where to put it and how to structure it. I will make a note of all of this information, and gather some more to build content for the section. Since I am moving this suggestion to the main discussion below, I move to close this. If anyone has any feedback regarding this please add it please. I move to close this so I may add it to the main section below. (All information has been saved in roder to reproduce if necessary.)
 +
::::::--[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 19:30, 3 December 2014 (UTC)
  
Cheers. --[[User:drevo|drevo]] 17:47, 6 January 2012 (EST)
+
:::::::Reopening this talk since I've hit this issue myself... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:31, 3 August 2015 (UTC)
  
 +
:::::::This issue gets very important now that disk encryption becomes more popular and users have to type their passphrase during grub boot phase. I think there has to be something in the documentation for setting a locale in grub2. As for Ubuntu, it works out of the box and I'd love to have a clean howto to change the keymap in GRUB2. Guess what ? A complete guaranteed recipe is hard to find on the net. Those comments where very handy for me.
 +
:::::::[[User:Skizorutabaga|Skizorutabaga]] ([[User talk:Skizorutabaga|talk]]) 18:05, 23 July 2016 (UTC)
  
 +
::::::::There is, for UEFI: [[GRUB/Tips_and_tricks#Manual_configuration_of_core_image_for_early_boot]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:10, 23 July 2016 (UTC)
  
 +
== grub standalone ==
  
The version  of ckbcomp I got from Debian Squeeze kept giving this error:
+
two things:
  
  Unknown name $sun_t6_custom
+
<s>1- I think the switch
 +
  --fonts="unicode"
 +
have to be removed since it is already the default behaviour
 +
(source: man grub-mkstandalone)
  
The Ubuntu Precise version worked out of the box.
+
2- before executing the command `grub-mkstandalone ...`, create the directory in your ''esp'' (e.g. /boot/EFI)
 +
otherwise it will fail
  
A temporary solution for layouts would be an AUR package for ckbcomp or to distribute .gkb files somehow, but the proper solution would be for grub-mklayout to accept keymaps(5) files.
+
--[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 09:34, 9 April 2016 (UTC)
 +
</s>
 +
'''done!''' --[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 17:28, 8 February 2017 (UTC)
  
--[[User:Schizius|Schizius]] ([[User talk:Schizius|talk]]) 18:44, 26 July 2012 (UTC)
+
== Grub Shell normal linux booting ==
  
== Please make the different options for changing the MBR more clear ==
+
A little improvement in GRUB Shell secction.
 +
When it is described the following example in [[GRUB#Using_the_rescue_console]]
  
The three options [https://wiki.archlinux.org/index.php/GRUB2#Install_grub-bios_boot_files here] are only separated by a bit unclear titles, and if people follow the links, they might be confused.[[User:Jasper1984|Jasper1984]] ([[User talk:Jasper1984|talk]]) 16:03, 20 July 2012 (UTC)
+
----
  
== Backing up grub-legacy bootcode ==
+
An example, booting Arch Linux:
  
Both grub2 and grub-legacy write to the space between the end of the MBR and the beginning of the first partition. I'm no expert on this matter; I just learned about it today.  That said, it makes me question the usefulness of the dd backup/restore method in the [https://wiki.archlinux.org/index.php/GRUB2#Backup_Important_Data Backup Important Data] section. --[[User:Alphaniner|Alphaniner]] ([[User talk:Alphaniner|talk]]) 20:07, 25 July 2012 (UTC)
+
  set root=(hd0,5)
:As far as I know, only GRUB2 uses the post-MBR gap. GRUB2 will notice when there is not enough space at the post-MBR gap and return a warning message (without overwriting anything, see [[https://wiki.archlinux.org/index.php/GRUB2#msdos-style_error_message]]) [[User:6arms1leg|6arms1leg]] ([[User talk:6arms1leg|talk]]) 15:45, 22 August 2012 (UTC)
+
linux /boot/vmlinuz-linux root=/dev/sda5
 +
initrd /boot/initramfs-linux.img
 +
boot
  
== GRUB2 + Windows 7 TrueCrypt-encrypted partition ==
+
With a separate boot partition (e.g. when using EFI), again change the lines accordingly:
 +
{{Note|Since boot is a separate partition and not part of your root partition, you must address the boot partition manually, in the same way as for the prefix variable.}}
  
[http://www.reddit.com/r/archlinux/comments/xdwsa/finally_did_the_grub2_update_migrating_away_from/ here is a link to my notes from my experience going thru this] and [http://ubuntuforums.org/showpost.php?p=10113708&postcount=25 Ubuntu Forum post which helped me a GREAT DEAL with this issue]
+
set root=(hd0,5)
- below is a quick HOWTO ::
+
linux (hdX,Y)/vmlinuz-linux root=/dev/sda6
 +
initrd (hdX,Y)/initramfs-linux.img
 +
boot
 +
----
  
# ls -al /mnt/win7drive/Users/me/Documents/TrueCrypt\ Rescue\ Disk.iso
+
I think it's imortant to say which partition is the root (/) and which is /boot, because it says sda5 and sda6, but it could be confusing. For example, to me, I don't really understand which is each one.
    -rwx------ 2 me users 1835008 Sep  5  2011 /mnt/win7/Users/me/Documents/TrueCrypt Rescue Disk.iso
+
Can someone explain it better? Thank you.
  
# sudo cp /mnt/win7/Users/me/Documents/TrueCrypt\ Rescue\ Disk.iso /boot/
+
[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 17:54, 13 August 2016 (UTC)
# mv /boot/TrueCrypt\ Rescue\ Disk.iso /boot/truecryptDesktop.iso
 
  
# pacman -S syslinux
+
:That is indeed confusing. I don't use GRUB, but I would guess that {{ic|1=set root=}} is setting the root of the ''console'' so that you can specify where the kernel/ramdisk is, which would be {{ic|/boot}}. Then when you boot linux you need to pass the usual kernel parameter {{ic|1=root=}} specifying where the linux filesystem is.
 +
:[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 19:34, 13 August 2016 (UTC)
  
# cp /usr/lib/syslinux/memdisk /boot/
 
  
# ls -alt /boot
+
:: Yes, I think is what you say. In facts, I tried to {{ic|1=set root=}} to my {{ic|/boot}} partition and then I specified the {{ic|1=root=}} for linux system, which is my partition mounted to {{ic|/ }} and it was OK. So I think we could explain it better in the wiki.
    total 26388
+
::[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 19:47, 13 August 2016 (UTC)
    drwxr-xr-x  5 root root    4096 Jul 29 04:01 .
 
    -rw-r--r--  1 root root    26140 Jul 29 04:01 memdisk
 
    -rwx------  1 root root  1835008 Jul 29 03:59 truecryptDesktop.iso
 
            ....  ....
 
  
#mount | grep /boot
+
== De-duplication of section header ==
    /dev/sda3 on /boot type ext3 (rw,relatime,data=ordered)
 
  
# vi /etc/grub.d/40_custom
+
ATM there is a duplicate header anchor:
+
* "Installation" links to the installation procedure for BIOS.
menuentry "Microsoft Windows 7 x64 Home Premium" {
+
* "Installation" &rarr; "Installation_2" links to the installation procedure for UEFI.
    insmod part_msdos
+
After some chat in IRC #archlinux-wiki, I am changing the second header from "Installation" to "Install", so to avoid this duplication of headers.
    set root='(hd0,msdos3)'
+
 
    linux16 ($root)/memdisk iso raw
+
In the same edition, I am also leaving a temporal manual anchor for "Installation_2", so as to minimize breaking links, considering the importance of this particular section of this particular wiki page.
    initrd16 ($root)/truecryptDesktop.iso
+
The reasoning for leaving a temporal manual anchor is that internal links are relatively easy to correct (right after renaming the header), whereas external links aren't.
}
+
 
 +
Examples of "external links" I am thinking about are:
 +
* Current / recent forum posts with links to the particular header / section.
 +
* Current / recent email threads / discussions with links to the particular header / section.
 +
* Other current / recent / relevant places / pages / sites with links to the particular header / section.
 +
The intention of this ''temporal'' manual anchor is to allow such potential recent links to still be valid (instead of leaving broken links), so users / readers / participants of conversations would still be able to make sense of such links and surrounding text / context, at least for some time.
 +
 
 +
Not every single header's renaming deserves leaving a (temporal) manual anchor (i.e. in most cases, I wouldn't be leaving a manual anchor) but in this case I consider this wiki page and this section to be particularly important / popular / relevant for too many users.
 +
 
 +
After some time, once current potential posts / emails containing links to the aforementioned section would be considered "old enough" (say, a month?), the manual anchor could be removed.
 +
 
 +
When I'm done with the edition I'll add a comment here. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 16:53, 6 March 2017 (UTC)
 +
 
 +
:What exactly was wrong with the duplicate header? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:14, 6 March 2017 (UTC)
  
# sudo grub-mkconfig -o /boot/grub/grub.cfg
+
:: Duplication of section headers are a potential problem because they generate an '''automatic''' anchor with a trailing number ("Installation", "Installation_2", "Installation_3") which can _vary_ depending on the location / order of the header within the page. IOW, moving a section means that a link such as <nowiki>[[GRUB#Installation_2]]</nowiki> would point to a different section than what was originally intended.
 +
:: Anyway, the edition is done [https://wiki.archlinux.org/index.php?title=GRUB&diff=469963&oldid=468802] and I also corrected the corresponding internal links (in the main namespace).
 +
:: I intend to remove the manual anchor in some time (a month?). [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 17:31, 6 March 2017 (UTC)
  
--[[User:Fnord0|Fnord0]] ([[User talk:Fnord0|talk]]) 17:59, 30 July 2012 (UTC)
+
:::Do you plan to change the order of these sections? Otherwise you're just solving a fabricated problem - the headings are like this this since [https://wiki.archlinux.org/index.php?title=GRUB&oldid=351695 2014] when they were changed from something completely different, I don't think there was ever a change which just changed the order of two sections with the same heading. If such problem really appeared in practice, the best solution would be to rename the sections after swapping them, which would invalidate the old links. This way old links will be invalidated for no reason and probably the first person wondering why these headings are different might rename them back for coherence. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:08, 6 March 2017 (UTC)
  
== grub-mkconfig with several os ==
+
::::Just in case and FWIW, for the very basic info about the matter, see https://en.wikipedia.org/wiki/Help:Link#Duplicate_section_names
 +
::::Renaming, moving, restructure... It happens all the time, with consequences. The fact that (some/many) editors don't notice / know / care about consequences of their editions doesn't mean that section header duplication is not a problem.
 +
::::Some editors don't even bother to summarize their editions, some of which are not always "the right thing to do".
 +
::::OTOH, I ask for feedback at IRC #archlinux-wiki, I explain the reasoning in the Talk Page, I perform the edition, I fill in a relevant edition summary, I take care of the internal links that are affected by the edition, and I also minimize the potential impact on external links (which many wiki editors and maintainers don't even consider before performing editions). Then I come back to the Talk Page to inform about the changes that were performed. I think I've done the right thing, and I think my edition was adequate. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 08:07, 7 March 2017 (UTC)
  
I use several OS (Windows, Arch, Ubuntu, Gentoo) on different partitions. os-prober only found Arch, Windows and Ubuntu -- strangely not Gentoo.  But when I mount the gentoo partition, it's found.  I don't know, whether this is the case, because I resized the partition, gentoo lives on, or whether this is the `default' behaviour. If so, should the Wiki mention that mounting the partitions help?
+
:::::I vote for reverting [https://wiki.archlinux.org/index.php?title=GRUB&curid=5984&diff=469963&oldid=468802], [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&curid=17198&diff=469964&oldid=467081] and [https://wiki.archlinux.org/index.php?title=Samsung_NP740U3L-L02US&diff=prev&oldid=469965]: having an "Installation" heading in the BIOS section, and "Install" in UEFI looks incoherent/unnatural, and as Lahwaacz points out, it just begs for somebody to fix it, which will happen sooner or later especially after removing the anchor (and hence breaking all its remaining backlinks), and even more especially if the article will really ever be radically restructured. In [[w:Help:Link#Duplicate_section_names]] the numbered suffix is presented as a feature, not a problem to work around, and IMO in general the least problematic way to edit the wiki is to do it in the way that the MediaWiki devs designed it. If one day we will have to swap "GRUB#Installation" links with "GRUB#Installation_2" we'll easily do it with a bot. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:48, 8 March 2017 (UTC)
  
--[[User:Skunk|Skunk]] ([[User talk:Skunk|talk]]) 19:46, 30 July 2012 (UTC)
+
::::::The Wikipedia link is the description of the feature, not the problem. The fact that the feature exists doesn't mean that duplication of headers is recommended or welcomed; on the contrary.
 +
::::::Had I performed a simple renaming on both headers and nothing more (as most editors do all the time, without caring / understanding its consequences), we would not be wasting time with this. Possibly I should not even care to edit at all. I think this simple matter is not worth spending more time on it. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 10:25, 8 March 2017 (UTC)
  
== Need simplified steps ==
+
:::::::>"Possibly I should not even care to edit at all"
 +
:::::::What I don't understand is why apparently it's often impossible to accept disagreement and different opinions without taking them as personal affronts. Even if an edit is minor it doesn't mean that it's accepted just because of that, nonetheless nobody has reverted your edits yet, Lahwaacz hasn't even taken a definitive stance on the matter, can we please keep calm an reasonable, also considering the very minor nature of this issue?
 +
:::::::Instead of winging we could discuss compromises such as renaming those headings in neater ways, e.g. "BIOS installation" and "UEFI installation". As I said we can always use bots to change the backlinks.
 +
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:29, 8 March 2017 (UTC)
  
I think [[GRUB2#Preliminary_Requirements_for_GRUB2]] part is optional in some cases. If so, it should be noted as optional.
+
::::::::I'm not taking this personally (although I do value my own time), and I'm OK with disagreements. My point is that if I would had performed the renaming in the same way as others do all the time, then we wouldn't be discussing it. I could say more, but I'd rather focus on practical results and not waste more time.
 +
::::::::WRT a different renaming as a compromise, I am very much in favor. In fact, my initial idea was to rename both headers, "Installation on BIOS" and "Installation on UEFI" (or "Install on..") respectively. But renaming both headers in this way would mean that:
 +
*even more external links could be potentially affected;
 +
*many more internal links would need to be updated in comparison to renaming only one of the headers (and I was doing them manually, one by one);
 +
*there was a disagreement in IRC #archlinux-wiki about adding "... BIOS" and "... UEFI" in the headers when they are already subsections under the respective BIOS and UEFI sections.
 +
::::::::Now, if ("Install on BIOS" and) "Install on UEFI" is/are acceptable &mdash; they are to me &mdash; please go ahead.
 +
::::::::In such case, leaving a temporal manual anchor also for the first header would be a plus IMO. [[User:Ady|Ady]] ([[User talk:Ady|talk]]) 12:44, 8 March 2017 (UTC)
  
{{Pkg|os-prober}} is quite useful, it should be put at the beginning of the articles, such as preparation.
+
:::::::::I agree with Kynikos that we should revert to the original, unproblematic state of headings until somebody comes up with a radical way to restructure the article's sections.
 +
:::::::::>"My point is that if I would had performed the renaming in the same way as others do all the time, then we wouldn't be discussing it."
 +
:::::::::You are right about this, in that case I would have simply reverted the renaming instead of joining this discussion.
 +
:::::::::>"leaving a temporal manual anchor also for the first header would be a plus"
 +
:::::::::FWIW I don't see any value in doing that. Internal links to the affected sections can be updated so quickly (with a bot) that it would be a waste of time, external links from resources that "don't care for updates" won't be updated anyway and external resources that absolutely need to preserve the temporal validity of the links should use [https://wiki.archlinux.org/index.php?title=GRUB&oldid=468802#Installation_2 permalinks]. Which alternative am I missing?
 +
:::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:50, 8 March 2017 (UTC)
  
In my case, I only did the backup, install grub-bios, install os-prober, [[GRUB2#Install_to_440-byte_MBR_boot_code_region]], edit {{ic|/etc/grub.d/40_custom}}, and finally grub-mkconfig. My computer is dual-boot with Windows 7.
+
::::::::::A simple reversion of those 3 edits was still my first choice, so I've jsut done it. I'm closing this discussion since apparently it didn't attract anybody else's interest: according to [[Help:Discussion]] it will still be visible at least for another week anyway. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:32, 9 March 2017 (UTC)
  
--[[User:Allencch|Allencch]] ([[User talk:Allencch|talk]]) 00:23, 1 August 2012 (UTC)
+
== Dual Booting Windows.  ==
  
== encrypted /boot ==
+
In the section on dual booting windows there is a section giving instructions for people booting BIOS-MBR
  
Just so I remember when I come back to edit the article, grub-install (2.00) currently requires the GRUB_CRYPTODISK_ENABLE environment variable be set to "y". --[[User:Buhman|Buhman]] ([[User talk:Buhman|talk]]) 05:58, 10 October 2012 (UTC)
 
  
== Possible mistake? ==
+
{{bc|1=
 +
if [ "${grub_platform}" == "pc" ]; then
 +
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {
 +
  insmod part_msdos
 +
  insmod ntfs
 +
  insmod search_fs_uuid
 +
  insmod ntldr   
 +
  search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE
 +
  ntldr /bootmgr
 +
}
 +
}
 +
}}
  
Hi there,
+
This probably works fine for most people. but if you run a BIOS-GPT setup to load GRUB and then want to load a BIOS-MBR windows setup on a separate drive. this wont work unless you remove the if statement. presumably the original author did not consider the fact that you could have both GPT and MBR in the same system on different drives.
since I do not feel familiar with Grub2 yet, you might check that:
 
  
[[GRUB2#Install_to_Partition_or_Partitionless_Disk]]
+
{{unsigned|18:46, 23 May 2017‎|Theholyduck}}
  
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX
+
:Perhaps what you indicated should be added in the same section or in another section regarding dual booting  Windows. Have you tested exactly what you stated and you know it works when you remove the if statement?
Should /dev/sdaX be /dev/sdX?
 
  
--[[User:Mrln|Mrln]] ([[User talk:Mrln|talk]]) 14:13, 1 March 2013 (UTC)
+
:[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)
: This section is about installing to partition. So it is indeed /dev/sdaX. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 08:43, 4 March 2013 (UTC)
 
  
 +
Has anyone besides the contributor got directly booting to work? [https://wiki.archlinux.org/index.php/GRUB#Windows_installed_in_BIOS-MBR_mode] I am the person who has added in the chainloading method because after some significant time I could not get the direct booting method working on my machine despite the fact that I do indeed have a BIOS-MBR configuration with Windows 10. I think we should have both methods because, as far as I know, the Arch Wiki has had the chainloading method available for a very long time and it always works. Further, Microsoft tends to do weird things with its files, so there's no telling when direct booting will or will not work depending on what Microsoft decides to do. By contrast, the chainloading method avoids this issue almost entirely.
  
--But the section does also have "Partitionless Disk" in its name, and there is the following text snippet just before the example given: "  to a partitionless disk (also called superfloppy) or to a floppy disk".
+
[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)
I am not sure, but afaik for a Partitionless Disk the syntax given is indeed wrong (should be /dev/sdX). Not sure how the section could be reworded to make it not-confusing. Giving two separate examples runs the danger of making the whole article too bloated. [[User:Bwid|Bwid]] ([[User talk:Bwid|talk]]) 09:35, 4 March 2013 (UTC)
 

Latest revision as of 17:07, 12 June 2017

Alpha sorting for kernel names without versions

When installing the "linux" and "linux-lts" kernels on a basic install, the /etc/grub.d/10_linux in 2.02-beta1 will try and use a numeric-oriented sorting routine that doesn't work well for kernels without any versions in the names of the files. I've submitted a feature request and patch for this upstream:

Forum discussion w/patch:

I solved this (and other problems) long ago… why nobody applied this patch to the Arch package is beyond me. felix (talk) 14:11, 8 August 2014 (UTC)
What is the current sate of this issue? --Stevenmw (talk) 10:56, 6 December 2014 (UTC)
I'd leave this open right now, as it seems a candidate for merging with GRUB/Tips and tricks#Multiple entries. -- Alad (talk) 19:36, 22 December 2014 (UTC)

Manually generate grub.cfg

In previous revisions, instructions on manually creating a grub.cfg were removed [1], and later added to GRUB/Tips and tricks [2]. This was discussed with [3]. However, as it turns out manually creating a grub.cfg is in fact encouraged upstream [4]. This is especially true in Arch as we don't have versioned kernels: FS#16702 (and thus no changing vmlinuz/initrd paths). As such I believe we should reduce the role of grub-mkconfig, expand on grub.cfg and move it back to the main article. -- Alad (talk) 14:24, 27 June 2015 (UTC)

I don't see a problem with this.
From upstream: In the meantime, those who feel that it would be easier to write grub.cfg directly are encouraged to do so... and to disable any system provided by their distribution to automatically run grub-mkconfig.
Correct me if I'm wrong here but I don't think we have anything that automatically calls grub-mkconfig. Therefore manually creating/editing grub.cfg shouldn't be a problem. -- Chazza (talk) 15:01, 27 June 2015 (UTC)
+1, this will also avoid random notes like this in other articles. -- Lahwaacz (talk) 19:21, 27 June 2015 (UTC)
Nothing calls grub-mkconfig, no. Yet, I tend to disagree. Reasons: (1) the article is still too long anyway and the fresh start on manually creating grub.cfg is a good base to expand in tips&tricks. (2) Reducing grub-mkconfig basically also means having to touch most content that covers the main options in /etc/default/grub. If I see it right, the Arch package comes with defaults there. (3) Thankfully grub-mkconfig automatically figures menu entry names, but also determines a root= UUID by default these days. The latter not a big problem for simple roots, but cumbersome to describe for others (e.g. when a device mapper is used, lvm, luks, ...). Likewise, grub-mkconfig also uses output from os-prober to automatically generate entries.
So, I don't think it is a straight-forward task and make things clearer. The instances one would save on "Now re-generate the configuration: ..." would probably have to be replaced with "Now better check the result with grub-script-check /boot/grub/grub.cfg" ... I think it would be better to give GRUB/Tips and tricks#Manually creating grub.cfg more prominence and expand the fresh base there as required/wanted. Also some of the lengthy menu entry examples of GRUB#Automatically generating using .2Fetc.2Fgrub.d.2F40 custom and grub-mkconfig could be moved to a section there; they basically work/serve as examples for both (copy pasting into /etc/grub.d/40_custom or /boot/grub/grub.cfg). --Indigo (talk) 21:51, 27 June 2015 (UTC)
I agree with Indigo. -- 6arms1leg (talk) 12:48, 28 June 2015 (UTC)
About (1), the inclusion on manually generating grub.cfg would be accompanied by (another, but needed) rewrite of the GRUB article. On (2), similar argument as in (1), and things like modules can be expanded on where needed. (3) It's not because you're not using grub-mkconfig, that you won't use tools such as grub-probe and grub-script-check to facilitate some tasks.
As to clarity, most people just run "grub-mkconfig" without understanding the process at hand, and as such, have difficulties when problems arise.
Note: I won't have much time to work on this (besides other tasks, I'd prefer to create fdisk first). -- Alad (talk) 15:48, 28 July 2015 (UTC)

Custom keyboard layout

Hi. Could we add a section explaining how you can set your preferred keyboard layout within GRUB2? As i found here, we need the ckbcomp script, which can be obtained from Debian console-setup package.

Here's how I made things work:

sudo mkdir /boot/grub/layouts
ckbcomp it |sudo grub-mklayout -o /boot/grub/layouts/it.gkb

Then, I manually edited /boot/grub/grub.cfg, adding the following lines:

/boot/grub/grub.cfg

terminal_input at_keyboard
keymap it

This worked for me, but as of now, i think it's a very dirty method. Is there some support for keyboard layouts within /etc/default/grub?

Cheers. --Hilinus 12:50, 26 December 2011 (EST)

I followed instructions on the grub-devel mailing list. First you insert
/etc/default/grub

GRUB_TERMINAL_INPUT=at_keyboard
in /etc/default/grub. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)
$ ckbcomp si | grub-mklayout -o si.gkb
Unknown key KP_Comma
Unknown key KP_Comma
Unknown key KP_Comma
Unknown key KP_Comma
Unknown keycode 0x79
$ sudo mv si.gkb /boot/grub/
After that you add
/etc/grub.d/40_custom

insmod keylayouts
keymap /boot/grub/si.gkb
to /etc/grub.d/40_custom and finally generate new grub.cfg with
$ sudo grub-mkconfig -o /boot/grub/grub.cfg
Cheers. --drevo 17:47, 6 January 2012 (EST)
The version of ckbcomp I got from Debian Squeeze kept giving this error:
Unknown name $sun_t6_custom
The Ubuntu Precise version worked out of the box.
A temporary solution for layouts would be an AUR package for ckbcomp or to distribute .gkb files somehow, but the proper solution would be for grub-mklayout to accept keymaps(5) files.
--Schizius (talk) 18:44, 26 July 2012 (UTC)
This won't work if /boot is on another root partition. At home / is on lvm and /boot on standard MBR partition. This was historical. But since grub.cfg is generated with the root partition in lvm, it can't find my keyboard layout.
The clean solution is to create a new file /etc/grub.d/50_keymapand put this:
#!/bin/sh
set -e
# Include the GRUB helper library for grub-mkconfig.
. /usr/share/grub/grub-mkconfig_lib
KEYMAP_FILE=/boot/grub/bepo.gkb
if ! prepare_grub_to_access_device "`${grub_probe} --target=device "${KEYMAP_FILE}"`"; then
	return 6--~~~~
fi
KEYMAP_FILE=$(make_system_path_relative_to_its_root "${KEYMAP_FILE}")
cat <<EOF
insmod keylayouts
keymap "${KEYMAP_FILE}"
EOF
So that the root partition is detected, loaded, and then the file is read within that partition.
--Glandos (talk) 08:23, 14 November 2013 (UTC)
Is Glandos's solution to be used in addition to the Perl script, or is it a standalone solution? I get the vague sense that it is to be used as an additional step only when your /boot is located in its own partition. If someone can clarify this, I will add the above steps to the wiki and test them out, because I was looking for a solution to this same issue. ingegnue (talk) 09:39, 5 October 2014 (UTC)
There is a discussion further down the page about restructuring and cleaning up the GRUB article. I will make a suggestion to add a section like this in that discussion. This way we can see how much demand there is for it and get suggestions about where to put it and how to structure it. I will make a note of all of this information, and gather some more to build content for the section. Since I am moving this suggestion to the main discussion below, I move to close this. If anyone has any feedback regarding this please add it please. I move to close this so I may add it to the main section below. (All information has been saved in roder to reproduce if necessary.)
--Stevenmw (talk) 19:30, 3 December 2014 (UTC)
Reopening this talk since I've hit this issue myself... -- Alad (talk) 06:31, 3 August 2015 (UTC)
This issue gets very important now that disk encryption becomes more popular and users have to type their passphrase during grub boot phase. I think there has to be something in the documentation for setting a locale in grub2. As for Ubuntu, it works out of the box and I'd love to have a clean howto to change the keymap in GRUB2. Guess what ? A complete guaranteed recipe is hard to find on the net. Those comments where very handy for me.
Skizorutabaga (talk) 18:05, 23 July 2016 (UTC)
There is, for UEFI: GRUB/Tips_and_tricks#Manual_configuration_of_core_image_for_early_boot. -- Lahwaacz (talk) 18:10, 23 July 2016 (UTC)

grub standalone

two things:

1- I think the switch

--fonts="unicode"

have to be removed since it is already the default behaviour (source: man grub-mkstandalone)

2- before executing the command `grub-mkstandalone ...`, create the directory in your esp (e.g. /boot/EFI) otherwise it will fail

--nTia89 (talk) 09:34, 9 April 2016 (UTC) done! --nTia89 (talk) 17:28, 8 February 2017 (UTC)

Grub Shell normal linux booting

A little improvement in GRUB Shell secction. When it is described the following example in GRUB#Using_the_rescue_console


An example, booting Arch Linux:

set root=(hd0,5)
linux /boot/vmlinuz-linux root=/dev/sda5
initrd /boot/initramfs-linux.img
boot

With a separate boot partition (e.g. when using EFI), again change the lines accordingly:

Note: Since boot is a separate partition and not part of your root partition, you must address the boot partition manually, in the same way as for the prefix variable.
set root=(hd0,5)
linux (hdX,Y)/vmlinuz-linux root=/dev/sda6
initrd (hdX,Y)/initramfs-linux.img
boot

I think it's imortant to say which partition is the root (/) and which is /boot, because it says sda5 and sda6, but it could be confusing. For example, to me, I don't really understand which is each one. Can someone explain it better? Thank you.

Cmolina (talk) 17:54, 13 August 2016 (UTC)

That is indeed confusing. I don't use GRUB, but I would guess that set root= is setting the root of the console so that you can specify where the kernel/ramdisk is, which would be /boot. Then when you boot linux you need to pass the usual kernel parameter root= specifying where the linux filesystem is.
Silverhammermba (talk) 19:34, 13 August 2016 (UTC)


Yes, I think is what you say. In facts, I tried to set root= to my /boot partition and then I specified the root= for linux system, which is my partition mounted to / and it was OK. So I think we could explain it better in the wiki.
Cmolina (talk) 19:47, 13 August 2016 (UTC)

De-duplication of section header

ATM there is a duplicate header anchor:

  • "Installation" links to the installation procedure for BIOS.
  • "Installation" → "Installation_2" links to the installation procedure for UEFI.

After some chat in IRC #archlinux-wiki, I am changing the second header from "Installation" to "Install", so to avoid this duplication of headers.

In the same edition, I am also leaving a temporal manual anchor for "Installation_2", so as to minimize breaking links, considering the importance of this particular section of this particular wiki page. The reasoning for leaving a temporal manual anchor is that internal links are relatively easy to correct (right after renaming the header), whereas external links aren't.

Examples of "external links" I am thinking about are:

  • Current / recent forum posts with links to the particular header / section.
  • Current / recent email threads / discussions with links to the particular header / section.
  • Other current / recent / relevant places / pages / sites with links to the particular header / section.

The intention of this temporal manual anchor is to allow such potential recent links to still be valid (instead of leaving broken links), so users / readers / participants of conversations would still be able to make sense of such links and surrounding text / context, at least for some time.

Not every single header's renaming deserves leaving a (temporal) manual anchor (i.e. in most cases, I wouldn't be leaving a manual anchor) but in this case I consider this wiki page and this section to be particularly important / popular / relevant for too many users.

After some time, once current potential posts / emails containing links to the aforementioned section would be considered "old enough" (say, a month?), the manual anchor could be removed.

When I'm done with the edition I'll add a comment here. Ady (talk) 16:53, 6 March 2017 (UTC)

What exactly was wrong with the duplicate header? -- Lahwaacz (talk) 17:14, 6 March 2017 (UTC)
Duplication of section headers are a potential problem because they generate an automatic anchor with a trailing number ("Installation", "Installation_2", "Installation_3") which can _vary_ depending on the location / order of the header within the page. IOW, moving a section means that a link such as [[GRUB#Installation_2]] would point to a different section than what was originally intended.
Anyway, the edition is done [5] and I also corrected the corresponding internal links (in the main namespace).
I intend to remove the manual anchor in some time (a month?). Ady (talk) 17:31, 6 March 2017 (UTC)
Do you plan to change the order of these sections? Otherwise you're just solving a fabricated problem - the headings are like this this since 2014 when they were changed from something completely different, I don't think there was ever a change which just changed the order of two sections with the same heading. If such problem really appeared in practice, the best solution would be to rename the sections after swapping them, which would invalidate the old links. This way old links will be invalidated for no reason and probably the first person wondering why these headings are different might rename them back for coherence. -- Lahwaacz (talk) 18:08, 6 March 2017 (UTC)
Just in case and FWIW, for the very basic info about the matter, see https://en.wikipedia.org/wiki/Help:Link#Duplicate_section_names
Renaming, moving, restructure... It happens all the time, with consequences. The fact that (some/many) editors don't notice / know / care about consequences of their editions doesn't mean that section header duplication is not a problem.
Some editors don't even bother to summarize their editions, some of which are not always "the right thing to do".
OTOH, I ask for feedback at IRC #archlinux-wiki, I explain the reasoning in the Talk Page, I perform the edition, I fill in a relevant edition summary, I take care of the internal links that are affected by the edition, and I also minimize the potential impact on external links (which many wiki editors and maintainers don't even consider before performing editions). Then I come back to the Talk Page to inform about the changes that were performed. I think I've done the right thing, and I think my edition was adequate. Ady (talk) 08:07, 7 March 2017 (UTC)
I vote for reverting [6], [7] and [8]: having an "Installation" heading in the BIOS section, and "Install" in UEFI looks incoherent/unnatural, and as Lahwaacz points out, it just begs for somebody to fix it, which will happen sooner or later especially after removing the anchor (and hence breaking all its remaining backlinks), and even more especially if the article will really ever be radically restructured. In w:Help:Link#Duplicate_section_names the numbered suffix is presented as a feature, not a problem to work around, and IMO in general the least problematic way to edit the wiki is to do it in the way that the MediaWiki devs designed it. If one day we will have to swap "GRUB#Installation" links with "GRUB#Installation_2" we'll easily do it with a bot. — Kynikos (talk) 09:48, 8 March 2017 (UTC)
The Wikipedia link is the description of the feature, not the problem. The fact that the feature exists doesn't mean that duplication of headers is recommended or welcomed; on the contrary.
Had I performed a simple renaming on both headers and nothing more (as most editors do all the time, without caring / understanding its consequences), we would not be wasting time with this. Possibly I should not even care to edit at all. I think this simple matter is not worth spending more time on it. Ady (talk) 10:25, 8 March 2017 (UTC)
>"Possibly I should not even care to edit at all"
What I don't understand is why apparently it's often impossible to accept disagreement and different opinions without taking them as personal affronts. Even if an edit is minor it doesn't mean that it's accepted just because of that, nonetheless nobody has reverted your edits yet, Lahwaacz hasn't even taken a definitive stance on the matter, can we please keep calm an reasonable, also considering the very minor nature of this issue?
Instead of winging we could discuss compromises such as renaming those headings in neater ways, e.g. "BIOS installation" and "UEFI installation". As I said we can always use bots to change the backlinks.
Kynikos (talk) 11:29, 8 March 2017 (UTC)
I'm not taking this personally (although I do value my own time), and I'm OK with disagreements. My point is that if I would had performed the renaming in the same way as others do all the time, then we wouldn't be discussing it. I could say more, but I'd rather focus on practical results and not waste more time.
WRT a different renaming as a compromise, I am very much in favor. In fact, my initial idea was to rename both headers, "Installation on BIOS" and "Installation on UEFI" (or "Install on..") respectively. But renaming both headers in this way would mean that:
  • even more external links could be potentially affected;
  • many more internal links would need to be updated in comparison to renaming only one of the headers (and I was doing them manually, one by one);
  • there was a disagreement in IRC #archlinux-wiki about adding "... BIOS" and "... UEFI" in the headers when they are already subsections under the respective BIOS and UEFI sections.
Now, if ("Install on BIOS" and) "Install on UEFI" is/are acceptable — they are to me — please go ahead.
In such case, leaving a temporal manual anchor also for the first header would be a plus IMO. Ady (talk) 12:44, 8 March 2017 (UTC)
I agree with Kynikos that we should revert to the original, unproblematic state of headings until somebody comes up with a radical way to restructure the article's sections.
>"My point is that if I would had performed the renaming in the same way as others do all the time, then we wouldn't be discussing it."
You are right about this, in that case I would have simply reverted the renaming instead of joining this discussion.
>"leaving a temporal manual anchor also for the first header would be a plus"
FWIW I don't see any value in doing that. Internal links to the affected sections can be updated so quickly (with a bot) that it would be a waste of time, external links from resources that "don't care for updates" won't be updated anyway and external resources that absolutely need to preserve the temporal validity of the links should use permalinks. Which alternative am I missing?
-- Lahwaacz (talk) 15:50, 8 March 2017 (UTC)
A simple reversion of those 3 edits was still my first choice, so I've jsut done it. I'm closing this discussion since apparently it didn't attract anybody else's interest: according to Help:Discussion it will still be visible at least for another week anyway. — Kynikos (talk) 11:32, 9 March 2017 (UTC)

Dual Booting Windows.

In the section on dual booting windows there is a section giving instructions for people booting BIOS-MBR


if [ "${grub_platform}" == "pc" ]; then
 menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {
   insmod part_msdos
   insmod ntfs
   insmod search_fs_uuid
   insmod ntldr     
   search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE
   ntldr /bootmgr
 }
}

This probably works fine for most people. but if you run a BIOS-GPT setup to load GRUB and then want to load a BIOS-MBR windows setup on a separate drive. this wont work unless you remove the if statement. presumably the original author did not consider the fact that you could have both GPT and MBR in the same system on different drives.

—This unsigned comment is by Theholyduck (talk) 18:46, 23 May 2017‎. Please sign your posts with ~~~~!

Perhaps what you indicated should be added in the same section or in another section regarding dual booting Windows. Have you tested exactly what you stated and you know it works when you remove the if statement?
Alchemek (talk) 17:07, 12 June 2017 (UTC)

Has anyone besides the contributor got directly booting to work? [9] I am the person who has added in the chainloading method because after some significant time I could not get the direct booting method working on my machine despite the fact that I do indeed have a BIOS-MBR configuration with Windows 10. I think we should have both methods because, as far as I know, the Arch Wiki has had the chainloading method available for a very long time and it always works. Further, Microsoft tends to do weird things with its files, so there's no telling when direct booting will or will not work depending on what Microsoft decides to do. By contrast, the chainloading method avoids this issue almost entirely.

Alchemek (talk) 17:07, 12 June 2017 (UTC)