https://wiki.archlinux.org/api.php?action=feedcontributions&user=Lo1&feedformat=atomArchWiki - User contributions [en]2024-03-29T13:45:20ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:GNS3&diff=504662Talk:GNS32017-12-27T17:09:34Z<p>Lo1: Replied to IGwadaa</p>
<hr />
<div>== VPCS ==<br />
Usually, a basic GNS3 installation is vpcs enabled, but binaries need to be downloaded. Should i add some reference in the main page?<br />
<br />
''[[User:Unknown|Unknown]]''<br />
<br />
Of course, please you can ! :) (please you delete the VPSC part after editing the wiki please)<br />
<br />
[[User:IGwadaa|IGwadaa]] ([[User talk:IGwadaa|talk]]) 16:38, 27 December 2017 (UTC)<br />
<br />
Sorry, it was me who made the edit in the wiki but I forgot to sign my post. <br />
Did you mean that I should delete the vpcs talk here? [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 17:09, 27 December 2017 (UTC)Lo1<br />
<br />
== Known Issues ==<br />
GNS 2.0.3 has this known issue: the server won't stop once the gui is closed, a popup appears after a while asking if one would like to kill it. We could create a Know Issues category for this and any other notes.<br />
<br />
[[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 21:28, 23 October 2017 (UTC)Lo1</div>Lo1https://wiki.archlinux.org/index.php?title=Talk:Ppp&diff=501314Talk:Ppp2017-12-07T09:33:21Z<p>Lo1: updates about chap and pap</p>
<hr />
<div>==PPPoE - Chap and Pap==<br />
I'm seeing that the wiki states that (perhaps in a "home-network" situation?) it is safe to choose either one or the other of the above authentication protocol. Wouldn't it be better to explain that using pap in productivity networks may be harmful (due to the fact that password are sent in clear text)?<br />
[[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 20:34, 5 December 2017 (UTC)Lo1<br />
<br />
Edit: [[ppp#Configuration|done]]. Let me know if you're not comfortable with these changes. [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 09:33, 7 December 2017 (UTC)Lo1</div>Lo1https://wiki.archlinux.org/index.php?title=Ppp&diff=501313Ppp2017-12-07T09:28:34Z<p>Lo1: external link to an explanation of pap vs chap, the former should not be used, when possible, to avoid security holes</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Networking]]<br />
[[ja:Pppd]]<br />
[[ru:Pppd]]<br />
<br />
'''ppp''' (Paul's PPP Package) is an open source package which implements the [[Wikipedia:point-to-point protocol|point-to-point protocol]] (PPP) on Linux and Solaris systems. It is implemented as single ''pppd'' daemon and acts as backend for {{Pkg|xl2tpd}}, {{Pkg|pptpd}} and [[netctl]]. [[Wikipedia:3G|3G]], [[Wikipedia:L2TP|L2TP]] and [[Wikipedia:PPPoE|PPPoE]] connections are internally based on PPP protocol and therefore can be managed by ppp.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|ppp}} package.<br />
<br />
Make sure that your kernel is compiled with PPPoE support (present in default kernel):<br />
<br />
{{hc|1=$ zgrep CONFIG_PPPOE /proc/config.gz|<br />
2=CONFIG_PPPOE=m}}<br />
<br />
== Configuration ==<br />
<br />
=== PPPoE ===<br />
<br />
Create the connection configuration file:<br />
<br />
{{hc|/etc/ppp/peers/''your_provider''|<br />
plugin rp-pppoe.so<br />
# rp_pppoe_ac 'your ac name'<br />
# rp_pppoe_service 'your service name'<br />
<br />
# network interface<br />
eth0<br />
# login name<br />
name "''someloginname''"<br />
usepeerdns<br />
persist<br />
# Uncomment this if you want to enable dial on demand<br />
#demand<br />
#idle 180<br />
defaultroute<br />
hide-password<br />
noauth}}<br />
<br />
If {{ic|usepeerdns}} option is used, ''pppd'' will create the {{ic|/etc/ppp/resolv.conf}} file with obtained DNS addresses while establishing a connection. By default, the {{ic|/etc/ppp/ip-up.d/00_dns}} hook script moves this file to {{ic|/etc/resolv.conf}}, allowing the system to use these name servers. If this is undesirable (e.g. you are using a local caching DNS), edit the {{ic|/etc/ppp/ip-up.d/00_dns.sh}} as you need.<br />
<br />
Put a line like this in {{ic|/etc/ppp/pap-secrets}} or {{ic|/etc/ppp/chap-secrets}} as required by the authentication method used by your ISP.<br />
<br />
Chap should always be preferred, when possible, if aiming at security (to understand how chap works see [http://www.tldp.org/LDP/nag/node120.html this]), however it is OK to write these two files at the same time, ''pppd'' will automatically use the appropriate one:<br />
<br />
''someloginname'' * ''yourpassword''<br />
<br />
You can now start the link using the command:<br />
<br />
# pppd call ''your_provider''<br />
<br />
Alternatively, you can use this<br />
<br />
# pon ''your_provider''<br />
<br />
where ''your_provider'' is the exact name of your options file in {{ic|/etc/ppp/peers}}.<br />
<br />
To see whether your PPPoE connection is started correctly, check the ''pppd'' output in system logs:<br />
<br />
# journalctl -b --no-pager | grep pppd<br />
<br />
On a successful connection, you will see something like the following:<br />
<br />
Jul 09 22:42:33 localhost pppd[239]: Plugin rp-pppoe.so loaded.<br />
Jul 09 22:42:33 localhost pppd[239]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.6<br />
Jul 09 22:42:33 localhost network[184]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.6<br />
Jul 09 22:42:33 localhost pppd[239]: pppd 2.4.6 started by root, uid 0<br />
Jul 09 22:42:39 localhost pppd[239]: PPP session is 292<br />
Jul 09 22:42:39 localhost pppd[239]: Connected to a0:f3:e4:4f:e3:b0 via interface enp4s0<br />
Jul 09 22:42:39 localhost pppd[239]: Using interface ppp0<br />
Jul 09 22:42:39 localhost pppd[239]: Connect: ppp0 <--> enp4s0<br />
Jul 09 22:42:39 localhost pppd[239]: CHAP authentication succeeded: CHAP authentication success<br />
Jul 09 22:42:39 localhost pppd[239]: CHAP authentication succeeded<br />
Jul 09 22:42:39 localhost pppd[239]: peer from calling number A0:F3:E4:4F:E3:B0 authorized<br />
Jul 09 22:42:39 localhost pppd[239]: Cannot determine ethernet address for proxy ARP<br />
Jul 09 22:42:39 localhost pppd[239]: local IP address 10.6.2.137<br />
Jul 09 22:42:39 localhost pppd[239]: remote IP address 10.6.1.1<br />
Jul 09 22:42:39 localhost pppd[239]: primary DNS address 10.6.1.1<br />
Jul 09 22:42:39 localhost pppd[239]: secondary DNS address 210.21.196.6<br />
<br />
By default the configuration in {{ic|/etc/ppp/peers/provider}} is treated as the default, so if you want to make "your_provider" the default, you can create a link like this<br />
<br />
# ln -s /etc/ppp/peers/''your_provider'' /etc/ppp/peers/provider<br />
<br />
Now you can start the link by simply running:<br />
<br />
# pon<br />
<br />
To close a connection, use this<br />
<br />
# poff ''your_provider''<br />
=== Easy wizard configuration ===<br />
<br />
{{Aur|pppconfig}} provides a dialog interface to create pppd configuration easily. The usage is as simple as running {{ic|pppconfig}} as root and it will guide the configuration creation.<br />
<br />
<pre><br />
# pppconfig --dialog<br />
</pre><br />
<br />
The resulting configuration can be called using {{ic|pon}} and discarded using {{ic|poff}} as mentioned before.<br />
<br />
=== Starting pppd on boot ===<br />
<br />
* Configure the {{ic|ppp_generic}} module to load on boot. See [[Kernel modules#Automatic module handling]] for more information.<br />
* [[Enable]] the systemd service {{ic|ppp@''your_provider''.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Do an auto redial ===<br />
<br />
If ''pppd'' is running, you can force a connection reset by sending the {{ic|SIGHUP}} signal to the process:<br />
<br />
# export PPPD_PID=$(pidof pppd)<br />
# kill -s HUP $PPPD_PID<br />
<br />
And you have redialed the connection.<br />
<br />
{{Note|Make sure you have {{ic|persist}} option enabled in your {{ic|/etc/ppp/peers/provider}} tab. Additionally you might want to set {{ic|holdoff 0}} to reconnect without waiting.}}<br />
<br />
=== ISP auto-disconnect after 24h ===<br />
<br />
{{Note|If you are not running your computer always on (running 24/7) then you can skip this step.}}<br />
<br />
If you use a flat-rate always-on connection on a computer, some providers restart your connection after 24h. That makes sure that the IP is rotated every 24h. To compensate, you can use an dynamic DNS service in combination with {{AUR|inadyn}}{{Broken package link|{{aur-mirror|inadyn}}}} to compensate for the rotating IP address. But to avoid disconnects when you do not need it, you might try to restart the connection using a cron job or [[systemd#Timers|systemd]] timer at a time of day you know no one will be using the connection (e.g. at 4 AM).<br />
<br />
==== Using cron ====<br />
<br />
{{Note| There are many [[cron]] implementations, but none of them are installed by default as the base system uses [[systemd/Timers]] instead.}}<br />
<br />
As root, do the following:<br />
<br />
Create a bash script similar to this and give it a name (e.g. {{ic|pppd_redial.sh}}):<br />
<br />
#!/bin/bash<br />
<br />
message="Restarting the PPP connection @:" $(date)<br />
pppd_id=$(pidof pppd)<br />
<br />
kill -s HUP $pppd_id<br />
echo $message<br />
<br />
Give it execute permissions and put it on a path visible to root.<br />
<br />
Then create a cron job using {{ic|crontab -e}}. Check that your {{ic|EDITOR}} env variable is set if the command fails. So add anywhere in the file,<br />
<br />
0 4 * * * /bin/bash /root/pppd_redial.sh<br />
<br />
Confirm that {{ic|cronie}} service is up and running. If this is not the case, just [[enable]] and [[start]] it.<br />
<br />
Save and exit. Your PPPoE connection will now restart every day at 4AM.<br />
<br />
==== Using a systemd timer ====<br />
<br />
An alternative way to force a reconnect is using a [[systemd]] timer and the ''poff'' script (in particular its {{ic|-r}} option). Simply create a ''.service'' and ''.timer'' files with the same name:<br />
{{hc|ppp-redial.timer|<nowiki><br />
[Unit]<br />
Description=Reconnect PPP connections daily<br />
<br />
[Timer]<br />
OnCalendar=*-*-* 05:00:00<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
{{hc|ppp-redial.service|<nowiki><br />
[Unit]<br />
Description=Reconnect PPP connections<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/poff -r<br />
</nowiki>}}<br />
<br />
Now just [[enable]] and [[start]] the timer and systemd will cause a restart at the specified time.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Default route ===<br />
<br />
If you have a preconfigured default route before the ''pppd'' is started, the default route is kept, so take a look in {{ic|/var/log/errors.log}} and if you have something like:<br />
<br />
pppd[nnnn]: not replacing existing default route via ''xxx.xxx.xxx.xxx''<br />
<br />
and {{ic|xxx.xxx.xxx.xxx}} is not the correct route for you<br />
<br />
* Create a new script in {{ic|/etc/ppp/ip-pre-up.d}} with this content:<br />
<br />
{{hc|/etc/ppp/ip-pre-up.d/10-route-del-default.sh|<br />
#!/bin/sh<br />
/usr/bin/route del default<br />
}}<br />
<br />
Note: Make sure you have a script named 'ip-pre-up' which launches *.sh in 'ip-pre-up.d' like other launch scripts do.<br />
<br />
* [[Restart]] the {{ic|pppd}} service.<br />
<br />
=== Masquerading seems to be working fine but some sites do not work ===<br />
<br />
The MTU under pppoe is 1492 bytes. Most sites use an MTU of 1500. So your connection sends an ICMP 3:4 (fragmentation needed) packet, asking for a smaller MTU, but some sites have their firewall blocking that.<br />
<br />
Enabling the PMTU clamping in [[iptables]] can solve that:<br />
<br />
iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu<br />
<br />
Now, for some reason, just trying to save the resulting iptables configuration with ''iptables-save'' and restoring it later, does not work. It has to be executed after the other iptables configuration had been loaded. So, here is a systemd unit to solve it:<br />
<br />
{{hc|pmtu-clamping.service|<nowiki><br />
[Unit]<br />
Description=PMTU clamping for pppoe<br />
Requires=iptables.service<br />
After=iptables.service<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/bin/iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
</nowiki>}}<br />
<br />
And [[enable]] it.<br />
<br />
=== pppd cannot load kernel module ppp_generic ===<br />
<br />
When starting PPTP client, the ''pppd'' process cannot locate the appropriate module:<br />
<br />
Couldn't open the /dev/ppp device: No such device or address<br />
Please load the ppp_generic kernel module.<br />
<br />
The solution is to edit the {{ic|/etc/modprobe.d/modules.conf}} file and change<br />
<br />
alias char-major-108 ppp<br />
<br />
to<br />
<br />
alias char-major-108 ppp_generic<br />
<br />
or just add such alias if it does not exist.<br />
<br />
The correct module will be loaded after reboot.</div>Lo1https://wiki.archlinux.org/index.php?title=Talk:Ppp&diff=501178Talk:Ppp2017-12-05T20:34:48Z<p>Lo1: pap and chap, suggesting clarification</p>
<hr />
<div>==PPPoE - Chap and Pap==<br />
I'm seeing that the wiki states that (perhaps in a "home-network" situation?) it is safe to choose either one or the other of the above authentication protocol. Wouldn't it be better to explain that using pap in productivity networks may be harmful (due to the fact that password are sent in clear text)?<br />
[[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 20:34, 5 December 2017 (UTC)Lo1</div>Lo1https://wiki.archlinux.org/index.php?title=GNS3&diff=496326GNS32017-11-13T16:50:53Z<p>Lo1: added wireshark section, installing wireshark is simple but some instructions may be needed to use it from within gns3</p>
<hr />
<div>[[Category:Networking]]<br />
[[Category:Emulators]]<br />
[[Category:Virtualization]]<br />
[[ja:GNS3]]<br />
{{Out of date}}<br />
<br />
[https://www.gns3.com/ GNS3] is a '''G'''raphical '''N'''etwork '''S'''imulator. It allows you to simulate a network on your computer.<br />
<br />
From the webpage:<br />
:''GNS3 is an open source software that simulate complex networks while being as close as possible to the way real networks perform. All of this without having dedicated network hardware such as routers and switches.''<br />
<br />
== Installation ==<br />
<br />
The {{AUR|gns3-gui}} and {{AUR|gns3-server}} packages are needed to run the GNS3 GUI. Both of which can be obtained from [[AUR]].<br />
<br />
== Adding virtual machines ==<br />
When creating your topology (your virtual network), you most likely want to add machines to it. GNS3 supports [[QEMU]] and [[VirtualBox]] out of the box. [[VMware]] does not make for as easy integration. You can use VMWare but you can not add the machines directly in your topology as you can with [[QEMU]] and [[VirtualBox]].<br />
<br />
=== VirtualBox ===<br />
==== Install VirtualBox ====<br />
<br />
To use VirtualBox-machines for your topology you need to [[install]] {{pkg|virtualbox}} and {{pkg|virtualbox-sdk}}. To avoid any problems with GNS3 not finding virtualbox it is recommended to install virtualbox AFTER you install GNS3. If you already have virtualbox installed, you should be able to just reinstall it.<br />
<br />
If you don't install the {{pkg|virtualbox-sdk}} package you will not get the {{ic|vboxapi.py}} script and GNS3s {{ic|vboxwrapper.py}} needs this to connect the VMs.<br />
<br />
==== Adding the GNS3 VM to VirtualBox ====<br />
The official GNS3 VM should be used to increase performance. Go to [https://github.com/GNS3/gns3-gui/releases\ GNS3 Github] and download the VirtualBox version of the GNS3 VM with the exact same version number as your GNS3 version. Unzip and import the VM in VirtualBox.<br />
<br />
To create a network connection between the GNS3 VM and the host OS a host-only network must be configured. In VirtualBox > Preferences > Network, set up a host-only network. In most cases, it will be called vboxnet0 or similar. Note the IP address dedicated to the interface in the GUI. For some reason, VirtualBox does not assign the IP to the interface, nor does it enable it. Therefore, this must be performed manually in the terminal. See [[Network configuration#Manual assignment]] for more information on assigning IP addresses.<br />
<br />
# ip addr add ''IP_address''/''subnet_mask'' dev vboxnet0<br />
# ip link set dev vboxnet0 up<br />
<br />
Launch the GNS3 startup wizard and select the GNS3 VM and it should be able to start the VM.<br />
<br />
==== Adding VMs to GNS3 ====<br />
When the connection between GNS3 and VirtualBox have been made you need to tell GNS3 which VMs it should see and be able to use.<br />
<br />
#In GNS3, click on Preferences -> VirtualBox. Check that the path to vboxwrapper.py (should be {{ic|/usr/share/gns3/vboxwrapper.py}} and is set per default) is correct (if you get an OK when pressing the "Test Settings"-button, it works, otherwise see the installation step).<br />
#Go to the VirtualBox Guest tab to add the VirtualBox VMs in GNS3. Choose an identifier name, a VM from the VM list (you may have to refresh the list using the provided button). To avoud confusion and possible errors, it is recomended to use the same identifier name as the name of the VM. When a VM is selected you can choose other options for it as well:<br />
#* Number of NICs is the number of network interface cards you will see inside your VM (e.g. ifconfig on Linux, if you have 4 NICs on your VM, then set it to 4 in GNS3, if you have 1 NIC, then set it to 1 in GNS3).<br />
#* Reserve first NIC for VirtualBox NAT to host OS is to you have your first network interface card (e.g. eth0 on Linux) configured with network address translation (NAT), allowing your VM to access your host network and Internet (if your host can access it of course).<br />
#* Enable console support to activate a serial console access to your VM. Please note that serial console support must also be configured on the operating system running in your VirtualBox guest for this feature to work. [http://help.ubuntu.com/community/SerialConsoleHowto Here is a howto for Debian/Ubuntu Linux].<br />
#* Enable console server (for remote access) is to remotely access to your VM serial console. GNS3 creates a mini Telnet server that act as a proxy between the serial console and Telnet clients. This feature requires the Enable console support to be enabled.<br />
#* Start in headless mode (without GUI) will hide the VirtualBox graphical interface when the VM is started. This option is mostly useful if you have configured the previously described console support.<br />
<br />
==== Adding VMs to your topology ====<br />
After you have told GNS3 which VMs is should be able to see you can drag'n'drop them in your topology. Simply select the computer-icon in the left sidebar. You can now choose "VirtualBox guest". Drag this to where you want to add your VM in your topology. When you drop it in you will be prompted about which VM to add. Select the one you want and click OK. You should now be able to boot the VM from GNS3 by right click -> start.<br />
<br />
=== Qemu ===<br />
To be written<br />
<br />
=== VMware ===<br />
==== Installation ====<br />
See [[VMware]].<br />
<br />
==== Adding VMs to your topology ====<br />
To use [[VMware]] in GNS3 you need to create a cloud in your GNS3 topology, and then in your VMware machine, connect it to the NIC of the cloud in your topology.<br />
<br />
Instructions taken (and ported) from [http://forum.gns3.net/topic1139.html GNS3 forums]:<br />
# Select network adapter "Host only" to your Virtual machine in Vmware<br />
# Check how this network adapter (vmnet1) is named ({{ic|ifconfig}} should list it).<br />
# Add a cloud to your workspace in GNS3.<br />
# Configure the cloud and select the network adapter you just looked up.<br />
#* Right Click on the cloud and select Configure.<br />
#* Select the C0 on the cloud.<br />
#* Select NIO Ethernet.<br />
#* Select Generic Ethernet NIO.<br />
#* Select the appropriate adapter from the drop-down menu and press the Add button.<br />
#* The adapter for your virtual machine should now be added to the cloud.<br />
# Connect cloud to your topology, for example to a router.<br />
# Assing IP addresses (in the same subnet) to the Virtual machine and the emulated router in GNS3.<br />
# Ping between router and virtual machine should now be successful, otherwise, try to redo the steps.<br />
<br />
== Connecting devices ==<br />
When devices have been added to your topology you will need to connect them. Select the link-icon (the bottom icon in the left sidebar, looks sort of like a mouse or ethernet-port+rj45 connector), click on a device (like a switch). Next, click on the device (like a VM) you want to connect to the switch. You will be promted to select the NIC which should be used. When you have created all the links you want, click the link-icon in the left sidebar to deselect it, otherwise GNS3 will still be in 'create link'-mode.<br />
<br />
== VPCS ==<br />
VPCS is a simple virtual PC simulator, supported by GNS3 and useful to enhance the simulation of a full working network topology. It can be downloaded from [https://sourceforge.net/projects/vpcs/files/ Sourceforge].<br />
The VPCS's executable should be placed inside ~/GNS3 to keep it simple, then GNS3 must be instructed to search the {{ic|path/to/executable}} (using GNS3 gui, the option is easily found under "Preferences").<br />
{{Note|VPCS 0.8b is affected from [https://gns3.com/discussions/vpcs-it-just-just-allow-type-one this] bug.}}<br />
<br />
== Wireshark packet capture==<br />
[[Wireshark]] can be used with GNS3 to "sniff" packets from the links between devices of a virtual topology. Install it, create a symlink under {{ic|~/GNS3/wireshark/}} directory, then change the settings to instruct GNS3 to use the right version; e.g. if using {{pkg|wireshark-gtk}}, opting for Wireshark Live Traffic Capture, go to Preferences, Packet capture preferences and change:<br />
tail -f -c +0b %c | wireshark -o "gui.window_title:%d" -k -i -<br />
to<br />
tail -f -c +0b %c | wireshark-gtk -o "gui.window_title:%d" -k -i -</div>Lo1https://wiki.archlinux.org/index.php?title=GNS3&diff=496324GNS32017-11-13T16:31:31Z<p>Lo1: added VPCS section, referring to external links. VPCS is fully supported from GNS3 and it's useful for topology troubleshooting.</p>
<hr />
<div>[[Category:Networking]]<br />
[[Category:Emulators]]<br />
[[Category:Virtualization]]<br />
[[ja:GNS3]]<br />
{{Out of date}}<br />
<br />
[https://www.gns3.com/ GNS3] is a '''G'''raphical '''N'''etwork '''S'''imulator. It allows you to simulate a network on your computer.<br />
<br />
From the webpage:<br />
:''GNS3 is an open source software that simulate complex networks while being as close as possible to the way real networks perform. All of this without having dedicated network hardware such as routers and switches.''<br />
<br />
== Installation ==<br />
<br />
The {{AUR|gns3-gui}} and {{AUR|gns3-server}} packages are needed to run the GNS3 GUI. Both of which can be obtained from [[AUR]].<br />
<br />
== Adding virtual machines ==<br />
When creating your topology (your virtual network), you most likely want to add machines to it. GNS3 supports [[QEMU]] and [[VirtualBox]] out of the box. [[VMware]] does not make for as easy integration. You can use VMWare but you can not add the machines directly in your topology as you can with [[QEMU]] and [[VirtualBox]].<br />
<br />
=== VirtualBox ===<br />
==== Install VirtualBox ====<br />
<br />
To use VirtualBox-machines for your topology you need to [[install]] {{pkg|virtualbox}} and {{pkg|virtualbox-sdk}}. To avoid any problems with GNS3 not finding virtualbox it is recommended to install virtualbox AFTER you install GNS3. If you already have virtualbox installed, you should be able to just reinstall it.<br />
<br />
If you don't install the {{pkg|virtualbox-sdk}} package you will not get the {{ic|vboxapi.py}} script and GNS3s {{ic|vboxwrapper.py}} needs this to connect the VMs.<br />
<br />
==== Adding the GNS3 VM to VirtualBox ====<br />
The official GNS3 VM should be used to increase performance. Go to [https://github.com/GNS3/gns3-gui/releases\ GNS3 Github] and download the VirtualBox version of the GNS3 VM with the exact same version number as your GNS3 version. Unzip and import the VM in VirtualBox.<br />
<br />
To create a network connection between the GNS3 VM and the host OS a host-only network must be configured. In VirtualBox > Preferences > Network, set up a host-only network. In most cases, it will be called vboxnet0 or similar. Note the IP address dedicated to the interface in the GUI. For some reason, VirtualBox does not assign the IP to the interface, nor does it enable it. Therefore, this must be performed manually in the terminal. See [[Network configuration#Manual assignment]] for more information on assigning IP addresses.<br />
<br />
# ip addr add ''IP_address''/''subnet_mask'' dev vboxnet0<br />
# ip link set dev vboxnet0 up<br />
<br />
Launch the GNS3 startup wizard and select the GNS3 VM and it should be able to start the VM.<br />
<br />
==== Adding VMs to GNS3 ====<br />
When the connection between GNS3 and VirtualBox have been made you need to tell GNS3 which VMs it should see and be able to use.<br />
<br />
#In GNS3, click on Preferences -> VirtualBox. Check that the path to vboxwrapper.py (should be {{ic|/usr/share/gns3/vboxwrapper.py}} and is set per default) is correct (if you get an OK when pressing the "Test Settings"-button, it works, otherwise see the installation step).<br />
#Go to the VirtualBox Guest tab to add the VirtualBox VMs in GNS3. Choose an identifier name, a VM from the VM list (you may have to refresh the list using the provided button). To avoud confusion and possible errors, it is recomended to use the same identifier name as the name of the VM. When a VM is selected you can choose other options for it as well:<br />
#* Number of NICs is the number of network interface cards you will see inside your VM (e.g. ifconfig on Linux, if you have 4 NICs on your VM, then set it to 4 in GNS3, if you have 1 NIC, then set it to 1 in GNS3).<br />
#* Reserve first NIC for VirtualBox NAT to host OS is to you have your first network interface card (e.g. eth0 on Linux) configured with network address translation (NAT), allowing your VM to access your host network and Internet (if your host can access it of course).<br />
#* Enable console support to activate a serial console access to your VM. Please note that serial console support must also be configured on the operating system running in your VirtualBox guest for this feature to work. [http://help.ubuntu.com/community/SerialConsoleHowto Here is a howto for Debian/Ubuntu Linux].<br />
#* Enable console server (for remote access) is to remotely access to your VM serial console. GNS3 creates a mini Telnet server that act as a proxy between the serial console and Telnet clients. This feature requires the Enable console support to be enabled.<br />
#* Start in headless mode (without GUI) will hide the VirtualBox graphical interface when the VM is started. This option is mostly useful if you have configured the previously described console support.<br />
<br />
==== Adding VMs to your topology ====<br />
After you have told GNS3 which VMs is should be able to see you can drag'n'drop them in your topology. Simply select the computer-icon in the left sidebar. You can now choose "VirtualBox guest". Drag this to where you want to add your VM in your topology. When you drop it in you will be prompted about which VM to add. Select the one you want and click OK. You should now be able to boot the VM from GNS3 by right click -> start.<br />
<br />
=== Qemu ===<br />
To be written<br />
<br />
=== VMware ===<br />
==== Installation ====<br />
See [[VMware]].<br />
<br />
==== Adding VMs to your topology ====<br />
To use [[VMware]] in GNS3 you need to create a cloud in your GNS3 topology, and then in your VMware machine, connect it to the NIC of the cloud in your topology.<br />
<br />
Instructions taken (and ported) from [http://forum.gns3.net/topic1139.html GNS3 forums]:<br />
# Select network adapter "Host only" to your Virtual machine in Vmware<br />
# Check how this network adapter (vmnet1) is named ({{ic|ifconfig}} should list it).<br />
# Add a cloud to your workspace in GNS3.<br />
# Configure the cloud and select the network adapter you just looked up.<br />
#* Right Click on the cloud and select Configure.<br />
#* Select the C0 on the cloud.<br />
#* Select NIO Ethernet.<br />
#* Select Generic Ethernet NIO.<br />
#* Select the appropriate adapter from the drop-down menu and press the Add button.<br />
#* The adapter for your virtual machine should now be added to the cloud.<br />
# Connect cloud to your topology, for example to a router.<br />
# Assing IP addresses (in the same subnet) to the Virtual machine and the emulated router in GNS3.<br />
# Ping between router and virtual machine should now be successful, otherwise, try to redo the steps.<br />
<br />
== Connecting devices ==<br />
When devices have been added to your topology you will need to connect them. Select the link-icon (the bottom icon in the left sidebar, looks sort of like a mouse or ethernet-port+rj45 connector), click on a device (like a switch). Next, click on the device (like a VM) you want to connect to the switch. You will be promted to select the NIC which should be used. When you have created all the links you want, click the link-icon in the left sidebar to deselect it, otherwise GNS3 will still be in 'create link'-mode.<br />
<br />
== VPCS ==<br />
VPCS is a simple virtual PC simulator, supported by GNS3 and useful to enhance the simulation of a full working network topology. It can be downloaded from [https://sourceforge.net/projects/vpcs/files/ Sourceforge].<br />
The VPCS's executable should be placed inside ~/GNS3 to keep it simple, then GNS3 must be instructed to search the path/to/executable (using GNS3 gui, the option is easily found under "Preferences").<br />
{{Note|VPCS 0.8b is affected from [https://gns3.com/discussions/vpcs-it-just-just-allow-type-one this] bug.}}</div>Lo1https://wiki.archlinux.org/index.php?title=Talk:GRUB&diff=494076Talk:GRUB2017-10-25T20:40:56Z<p>Lo1: typo2, corrected</p>
<hr />
<div>== Alpha sorting for kernel names without versions ==<br />
<br />
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:<br />
<br />
* https://savannah.gnu.org/bugs/index.php?42597<br />
<br />
Forum discussion w/patch:<br />
<br />
* https://bbs.archlinux.org/viewtopic.php?pid=1428523<br />
<br />
: [//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)<br />
<br />
::What is the current sate of this issue? --[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 10:56, 6 December 2014 (UTC)<br />
<br />
:::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)<br />
<br />
== Manually generate grub.cfg ==<br />
<br />
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].<br />
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)<br />
: I don't see a problem with this.<br />
: 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.'''''<br />
: 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)<br />
<br />
::+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)<br />
<br />
::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. <br />
::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)<br />
<br />
:::I agree with [[User:Indigo|Indigo]]. -- [[User:6arms1leg|6arms1leg]] ([[User talk:6arms1leg|talk]]) 12:48, 28 June 2015 (UTC)<br />
<br />
::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.<br />
::As to clarity, most people just run "grub-mkconfig" without understanding the process at hand, and as such, have difficulties when problems arise.<br />
::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)<br />
<br />
== Custom keyboard layout ==<br />
<br />
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.<br />
<br />
Here's how I made things work:<br />
<br />
sudo mkdir /boot/grub/layouts<br />
ckbcomp it |sudo grub-mklayout -o /boot/grub/layouts/it.gkb<br />
<br />
Then, I manually edited {{ic|/boot/grub/grub.cfg}}, adding the following lines:<br />
<br />
{{hc|/boot/grub/grub.cfg|<br />
<nowiki><br />
terminal_input at_keyboard<br />
keymap it<br />
</nowiki>}}<br />
<br />
This worked for me, but as of now, i think it's a very dirty method. Is there some support for keyboard layouts within {{ic|/etc/default/grub}}?<br />
<br />
Cheers. --[[User:Hilinus|Hilinus]] 12:50, 26 December 2011 (EST)<br />
<br />
:I followed [http://lists.gnu.org/archive/html/grub-devel/2011-03/msg00051.html instructions] on the grub-devel mailing list. First you insert <br />
<br />
{{hc|/etc/default/grub|<br />
<nowiki><br />
GRUB_TERMINAL_INPUT=at_keyboard<br />
</nowiki>}}<br />
<br />
:in {{ic|/etc/default/grub}}. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)<br />
<br />
:{{bc|<nowiki><br />
$ ckbcomp si | grub-mklayout -o si.gkb<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown keycode 0x79<br />
$ sudo mv si.gkb /boot/grub/<br />
</nowiki>}}<br />
<br />
:After that you add <br />
<br />
{{hc|/etc/grub.d/40_custom|<br />
<nowiki><br />
insmod keylayouts<br />
keymap /boot/grub/si.gkb<br />
</nowiki>}}<br />
<br />
:to {{ic|/etc/grub.d/40_custom}} and finally generate new grub.cfg with<br />
<br />
:{{bc|$ sudo grub-mkconfig -o /boot/grub/grub.cfg}}<br />
<br />
:Cheers. --[[User:drevo|drevo]] 17:47, 6 January 2012 (EST)<br />
<br />
::The version of ckbcomp I got from Debian Squeeze kept giving this error:<br />
<br />
::{{bc|Unknown name $sun_t6_custom}}<br />
<br />
::The Ubuntu Precise version worked out of the box.<br />
<br />
::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.<br />
<br />
::--[[User:Schizius|Schizius]] ([[User talk:Schizius|talk]]) 18:44, 26 July 2012 (UTC)<br />
<br />
:::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.<br />
:::The clean solution is to create a new file ''/etc/grub.d/50_keymap''and put this:<br />
<br />
:::{{bc|<nowiki><br />
#!/bin/sh<br />
set -e<br />
# Include the GRUB helper library for grub-mkconfig.<br />
. /usr/share/grub/grub-mkconfig_lib<br />
KEYMAP_FILE=/boot/grub/bepo.gkb<br />
if ! prepare_grub_to_access_device "`${grub_probe} --target=device "${KEYMAP_FILE}"`"; then<br />
return 6--~~~~<br />
fi<br />
KEYMAP_FILE=$(make_system_path_relative_to_its_root "${KEYMAP_FILE}")<br />
cat <<EOF<br />
insmod keylayouts<br />
keymap "${KEYMAP_FILE}"<br />
EOF<br />
</nowiki>}}<br />
<br />
:::So that the root partition is detected, loaded, and then the file is read within that partition.<br />
<br />
:::--[[User:Glandos|Glandos]] ([[User talk:Glandos|talk]]) 08:23, 14 November 2013 (UTC)<br />
<br />
::::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)<br />
<br />
::::::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.)<br />
::::::--[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 19:30, 3 December 2014 (UTC)<br />
<br />
:::::::Reopening this talk since I've hit this issue myself... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:31, 3 August 2015 (UTC)<br />
<br />
:::::::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.<br />
:::::::[[User:Skizorutabaga|Skizorutabaga]] ([[User talk:Skizorutabaga|talk]]) 18:05, 23 July 2016 (UTC)<br />
<br />
::::::::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)<br />
<br />
:::::::: grub-kbdcomp /tmp/fr.gkb fr can also create keyboard layout for at_keyboard<br />
::::::::Note that at_keyboard does not always work. If at_keyboard freeze your system, you may have to use use usb_keyboard or console, so you could not use your layout...<br />
::::::::cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741464<br />
::::::::{{unsigned|04:11, 29 July 2017|Ryuta}}<br />
<br />
== grub standalone ==<br />
<br />
two things:<br />
<br />
<s>1- I think the switch<br />
--fonts="unicode"<br />
have to be removed since it is already the default behaviour<br />
(source: man grub-mkstandalone)<br />
<br />
2- before executing the command `grub-mkstandalone ...`, create the directory in your ''esp'' (e.g. /boot/EFI)<br />
otherwise it will fail<br />
<br />
--[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 09:34, 9 April 2016 (UTC)<br />
</s><br />
'''done!''' --[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 17:28, 8 February 2017 (UTC)<br />
<br />
== Grub Shell normal linux booting ==<br />
<br />
A little improvement in GRUB Shell secction.<br />
When it is described the following example in [[GRUB#Using_the_rescue_console]]<br />
<br />
----<br />
<br />
An example, booting Arch Linux:<br />
<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition (e.g. when using EFI), again change the lines accordingly: <br />
{{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.}}<br />
<br />
set root=(hd0,5)<br />
linux (hdX,Y)/vmlinuz-linux root=/dev/sda6<br />
initrd (hdX,Y)/initramfs-linux.img<br />
boot<br />
----<br />
<br />
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.<br />
Can someone explain it better? Thank you.<br />
<br />
[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 17:54, 13 August 2016 (UTC)<br />
<br />
: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.<br />
:[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 19:34, 13 August 2016 (UTC)<br />
<br />
<br />
:: 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.<br />
::[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 19:47, 13 August 2016 (UTC)<br />
<br />
== De-duplication of section header ==<br />
<br />
ATM there is a duplicate header anchor:<br />
* "Installation" links to the installation procedure for BIOS.<br />
* "Installation" &rarr; "Installation_2" links to the installation procedure for UEFI.<br />
After some chat in IRC #archlinux-wiki, I am changing the second header from "Installation" to "Install", so to avoid this duplication of headers.<br />
<br />
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.<br />
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.<br />
<br />
Examples of "external links" I am thinking about are:<br />
* Current / recent forum posts with links to the particular header / section.<br />
* Current / recent email threads / discussions with links to the particular header / section.<br />
* Other current / recent / relevant places / pages / sites with links to the particular header / section.<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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)<br />
<br />
:What exactly was wrong with the duplicate header? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:14, 6 March 2017 (UTC)<br />
<br />
:: 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.<br />
:: 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).<br />
:: 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)<br />
<br />
:::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)<br />
<br />
::::Just in case and FWIW, for the very basic info about the matter, see https://en.wikipedia.org/wiki/Help:Link#Duplicate_section_names <br />
::::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.<br />
::::Some editors don't even bother to summarize their editions, some of which are not always "the right thing to do".<br />
::::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)<br />
<br />
:::::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)<br />
<br />
::::::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.<br />
::::::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)<br />
<br />
:::::::>"Possibly I should not even care to edit at all"<br />
:::::::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?<br />
:::::::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.<br />
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:29, 8 March 2017 (UTC)<br />
<br />
::::::::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.<br />
::::::::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:<br />
*even more external links could be potentially affected;<br />
*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);<br />
*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.<br />
::::::::Now, if ("Install on BIOS" and) "Install on UEFI" is/are acceptable &mdash; they are to me &mdash; please go ahead.<br />
::::::::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)<br />
<br />
:::::::::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.<br />
:::::::::>"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."<br />
:::::::::You are right about this, in that case I would have simply reverted the renaming instead of joining this discussion.<br />
:::::::::>"leaving a temporal manual anchor also for the first header would be a plus"<br />
:::::::::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?<br />
:::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:50, 8 March 2017 (UTC)<br />
<br />
::::::::::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)<br />
<br />
== Dual Booting Windows. ==<br />
<br />
In the section on dual booting windows there is a section giving instructions for people booting BIOS-MBR <br />
<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
}<br />
}}<br />
<br />
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.<br />
<br />
{{unsigned|18:46, 23 May 2017|Theholyduck}}<br />
<br />
: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?<br />
<br />
:[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)<br />
<br />
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.<br />
<br />
[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)<br />
<br />
:I'm chainloading too, tested the "normal" method to no avail when i got some problems installing GRUB. I would like to add, if one's machine is eqipped with an UEFI firmware, and the chosen partition table is MBR, before running through the installation it's better to check the boot preferences and/or select the proper USB drive method to boot, since UEFI boot manager may have a higher priority and "corrupt" the bootloader installation. Also, in this case, when booting an USB Archiso live one should be good-to-go if the coloured Arch Linux boot menu appears (instead of a minimal black screen/white font boot menu with some UEFI options). Forgetting or ignoring to check this before installing and configuring GRUB, lead to the result that Windows (in my case, 8.1) won't be booted (even after adding a proper 40_custom configuration) nor os-prober will be able to find it. Finally, as @Alchemek may guess, even in this case Windows needs to be booted by chainloading its boot manager. Documentation about this seems missing/scarce due to the singularity of the case, but i think adding it to the Wiki should do no harm. [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 20:40, 25 October 2017 (UTC)Lo1</div>Lo1https://wiki.archlinux.org/index.php?title=Talk:GRUB&diff=494075Talk:GRUB2017-10-25T20:39:31Z<p>Lo1: typo</p>
<hr />
<div>== Alpha sorting for kernel names without versions ==<br />
<br />
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:<br />
<br />
* https://savannah.gnu.org/bugs/index.php?42597<br />
<br />
Forum discussion w/patch:<br />
<br />
* https://bbs.archlinux.org/viewtopic.php?pid=1428523<br />
<br />
: [//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)<br />
<br />
::What is the current sate of this issue? --[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 10:56, 6 December 2014 (UTC)<br />
<br />
:::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)<br />
<br />
== Manually generate grub.cfg ==<br />
<br />
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].<br />
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)<br />
: I don't see a problem with this.<br />
: 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.'''''<br />
: 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)<br />
<br />
::+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)<br />
<br />
::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. <br />
::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)<br />
<br />
:::I agree with [[User:Indigo|Indigo]]. -- [[User:6arms1leg|6arms1leg]] ([[User talk:6arms1leg|talk]]) 12:48, 28 June 2015 (UTC)<br />
<br />
::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.<br />
::As to clarity, most people just run "grub-mkconfig" without understanding the process at hand, and as such, have difficulties when problems arise.<br />
::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)<br />
<br />
== Custom keyboard layout ==<br />
<br />
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.<br />
<br />
Here's how I made things work:<br />
<br />
sudo mkdir /boot/grub/layouts<br />
ckbcomp it |sudo grub-mklayout -o /boot/grub/layouts/it.gkb<br />
<br />
Then, I manually edited {{ic|/boot/grub/grub.cfg}}, adding the following lines:<br />
<br />
{{hc|/boot/grub/grub.cfg|<br />
<nowiki><br />
terminal_input at_keyboard<br />
keymap it<br />
</nowiki>}}<br />
<br />
This worked for me, but as of now, i think it's a very dirty method. Is there some support for keyboard layouts within {{ic|/etc/default/grub}}?<br />
<br />
Cheers. --[[User:Hilinus|Hilinus]] 12:50, 26 December 2011 (EST)<br />
<br />
:I followed [http://lists.gnu.org/archive/html/grub-devel/2011-03/msg00051.html instructions] on the grub-devel mailing list. First you insert <br />
<br />
{{hc|/etc/default/grub|<br />
<nowiki><br />
GRUB_TERMINAL_INPUT=at_keyboard<br />
</nowiki>}}<br />
<br />
:in {{ic|/etc/default/grub}}. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)<br />
<br />
:{{bc|<nowiki><br />
$ ckbcomp si | grub-mklayout -o si.gkb<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown keycode 0x79<br />
$ sudo mv si.gkb /boot/grub/<br />
</nowiki>}}<br />
<br />
:After that you add <br />
<br />
{{hc|/etc/grub.d/40_custom|<br />
<nowiki><br />
insmod keylayouts<br />
keymap /boot/grub/si.gkb<br />
</nowiki>}}<br />
<br />
:to {{ic|/etc/grub.d/40_custom}} and finally generate new grub.cfg with<br />
<br />
:{{bc|$ sudo grub-mkconfig -o /boot/grub/grub.cfg}}<br />
<br />
:Cheers. --[[User:drevo|drevo]] 17:47, 6 January 2012 (EST)<br />
<br />
::The version of ckbcomp I got from Debian Squeeze kept giving this error:<br />
<br />
::{{bc|Unknown name $sun_t6_custom}}<br />
<br />
::The Ubuntu Precise version worked out of the box.<br />
<br />
::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.<br />
<br />
::--[[User:Schizius|Schizius]] ([[User talk:Schizius|talk]]) 18:44, 26 July 2012 (UTC)<br />
<br />
:::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.<br />
:::The clean solution is to create a new file ''/etc/grub.d/50_keymap''and put this:<br />
<br />
:::{{bc|<nowiki><br />
#!/bin/sh<br />
set -e<br />
# Include the GRUB helper library for grub-mkconfig.<br />
. /usr/share/grub/grub-mkconfig_lib<br />
KEYMAP_FILE=/boot/grub/bepo.gkb<br />
if ! prepare_grub_to_access_device "`${grub_probe} --target=device "${KEYMAP_FILE}"`"; then<br />
return 6--~~~~<br />
fi<br />
KEYMAP_FILE=$(make_system_path_relative_to_its_root "${KEYMAP_FILE}")<br />
cat <<EOF<br />
insmod keylayouts<br />
keymap "${KEYMAP_FILE}"<br />
EOF<br />
</nowiki>}}<br />
<br />
:::So that the root partition is detected, loaded, and then the file is read within that partition.<br />
<br />
:::--[[User:Glandos|Glandos]] ([[User talk:Glandos|talk]]) 08:23, 14 November 2013 (UTC)<br />
<br />
::::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)<br />
<br />
::::::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.)<br />
::::::--[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 19:30, 3 December 2014 (UTC)<br />
<br />
:::::::Reopening this talk since I've hit this issue myself... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:31, 3 August 2015 (UTC)<br />
<br />
:::::::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.<br />
:::::::[[User:Skizorutabaga|Skizorutabaga]] ([[User talk:Skizorutabaga|talk]]) 18:05, 23 July 2016 (UTC)<br />
<br />
::::::::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)<br />
<br />
:::::::: grub-kbdcomp /tmp/fr.gkb fr can also create keyboard layout for at_keyboard<br />
::::::::Note that at_keyboard does not always work. If at_keyboard freeze your system, you may have to use use usb_keyboard or console, so you could not use your layout...<br />
::::::::cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741464<br />
::::::::{{unsigned|04:11, 29 July 2017|Ryuta}}<br />
<br />
== grub standalone ==<br />
<br />
two things:<br />
<br />
<s>1- I think the switch<br />
--fonts="unicode"<br />
have to be removed since it is already the default behaviour<br />
(source: man grub-mkstandalone)<br />
<br />
2- before executing the command `grub-mkstandalone ...`, create the directory in your ''esp'' (e.g. /boot/EFI)<br />
otherwise it will fail<br />
<br />
--[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 09:34, 9 April 2016 (UTC)<br />
</s><br />
'''done!''' --[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 17:28, 8 February 2017 (UTC)<br />
<br />
== Grub Shell normal linux booting ==<br />
<br />
A little improvement in GRUB Shell secction.<br />
When it is described the following example in [[GRUB#Using_the_rescue_console]]<br />
<br />
----<br />
<br />
An example, booting Arch Linux:<br />
<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition (e.g. when using EFI), again change the lines accordingly: <br />
{{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.}}<br />
<br />
set root=(hd0,5)<br />
linux (hdX,Y)/vmlinuz-linux root=/dev/sda6<br />
initrd (hdX,Y)/initramfs-linux.img<br />
boot<br />
----<br />
<br />
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.<br />
Can someone explain it better? Thank you.<br />
<br />
[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 17:54, 13 August 2016 (UTC)<br />
<br />
: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.<br />
:[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 19:34, 13 August 2016 (UTC)<br />
<br />
<br />
:: 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.<br />
::[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 19:47, 13 August 2016 (UTC)<br />
<br />
== De-duplication of section header ==<br />
<br />
ATM there is a duplicate header anchor:<br />
* "Installation" links to the installation procedure for BIOS.<br />
* "Installation" &rarr; "Installation_2" links to the installation procedure for UEFI.<br />
After some chat in IRC #archlinux-wiki, I am changing the second header from "Installation" to "Install", so to avoid this duplication of headers.<br />
<br />
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.<br />
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.<br />
<br />
Examples of "external links" I am thinking about are:<br />
* Current / recent forum posts with links to the particular header / section.<br />
* Current / recent email threads / discussions with links to the particular header / section.<br />
* Other current / recent / relevant places / pages / sites with links to the particular header / section.<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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)<br />
<br />
:What exactly was wrong with the duplicate header? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:14, 6 March 2017 (UTC)<br />
<br />
:: 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.<br />
:: 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).<br />
:: 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)<br />
<br />
:::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)<br />
<br />
::::Just in case and FWIW, for the very basic info about the matter, see https://en.wikipedia.org/wiki/Help:Link#Duplicate_section_names <br />
::::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.<br />
::::Some editors don't even bother to summarize their editions, some of which are not always "the right thing to do".<br />
::::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)<br />
<br />
:::::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)<br />
<br />
::::::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.<br />
::::::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)<br />
<br />
:::::::>"Possibly I should not even care to edit at all"<br />
:::::::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?<br />
:::::::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.<br />
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:29, 8 March 2017 (UTC)<br />
<br />
::::::::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.<br />
::::::::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:<br />
*even more external links could be potentially affected;<br />
*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);<br />
*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.<br />
::::::::Now, if ("Install on BIOS" and) "Install on UEFI" is/are acceptable &mdash; they are to me &mdash; please go ahead.<br />
::::::::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)<br />
<br />
:::::::::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.<br />
:::::::::>"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."<br />
:::::::::You are right about this, in that case I would have simply reverted the renaming instead of joining this discussion.<br />
:::::::::>"leaving a temporal manual anchor also for the first header would be a plus"<br />
:::::::::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?<br />
:::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:50, 8 March 2017 (UTC)<br />
<br />
::::::::::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)<br />
<br />
== Dual Booting Windows. ==<br />
<br />
In the section on dual booting windows there is a section giving instructions for people booting BIOS-MBR <br />
<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
}<br />
}}<br />
<br />
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.<br />
<br />
{{unsigned|18:46, 23 May 2017|Theholyduck}}<br />
<br />
: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?<br />
<br />
:[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)<br />
<br />
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.<br />
<br />
[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)<br />
<br />
:I'm chainloading too, tested the "normal" method to no avail when i got some problems installing GRUB. I would like to add, if one's machine is eqipped with an UEFI firmware, and the chosen partition table is MBR, before running through the installation it's better to check the boot preferences and/or select the proper USB drive method to boot, since UEFI boot manager may have a higher priority and "corrupt" the bootloader installation. Also, in this case, when booting an USB Archiso live one should be good-to-go if the coloured Arch Linux boot menu appears (instead of a minimal black screen/white font boot menu with some UEFI options). Forgetting or ignoring to check this before installing and configuring GRUB, lead to the result that Windows (in my case, 8.1) won't be booted (even after adding a proper 40_custom configuration) nor os-prober will be able to find it. Finally, as @Alchemek may guess, even in this case Windows needs to be booted by chainloading its boot manager. Documentation about this seems missing/scarce due to the singularity of the case, but i think adding it to the Wiki should do no harm.<br />
[[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 20:39, 25 October 2017 (UTC)Lo1</div>Lo1https://wiki.archlinux.org/index.php?title=Talk:GRUB&diff=494074Talk:GRUB2017-10-25T20:38:44Z<p>Lo1: space before my signature</p>
<hr />
<div>== Alpha sorting for kernel names without versions ==<br />
<br />
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:<br />
<br />
* https://savannah.gnu.org/bugs/index.php?42597<br />
<br />
Forum discussion w/patch:<br />
<br />
* https://bbs.archlinux.org/viewtopic.php?pid=1428523<br />
<br />
: [//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)<br />
<br />
::What is the current sate of this issue? --[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 10:56, 6 December 2014 (UTC)<br />
<br />
:::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)<br />
<br />
== Manually generate grub.cfg ==<br />
<br />
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].<br />
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)<br />
: I don't see a problem with this.<br />
: 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.'''''<br />
: 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)<br />
<br />
::+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)<br />
<br />
::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. <br />
::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)<br />
<br />
:::I agree with [[User:Indigo|Indigo]]. -- [[User:6arms1leg|6arms1leg]] ([[User talk:6arms1leg|talk]]) 12:48, 28 June 2015 (UTC)<br />
<br />
::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.<br />
::As to clarity, most people just run "grub-mkconfig" without understanding the process at hand, and as such, have difficulties when problems arise.<br />
::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)<br />
<br />
== Custom keyboard layout ==<br />
<br />
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.<br />
<br />
Here's how I made things work:<br />
<br />
sudo mkdir /boot/grub/layouts<br />
ckbcomp it |sudo grub-mklayout -o /boot/grub/layouts/it.gkb<br />
<br />
Then, I manually edited {{ic|/boot/grub/grub.cfg}}, adding the following lines:<br />
<br />
{{hc|/boot/grub/grub.cfg|<br />
<nowiki><br />
terminal_input at_keyboard<br />
keymap it<br />
</nowiki>}}<br />
<br />
This worked for me, but as of now, i think it's a very dirty method. Is there some support for keyboard layouts within {{ic|/etc/default/grub}}?<br />
<br />
Cheers. --[[User:Hilinus|Hilinus]] 12:50, 26 December 2011 (EST)<br />
<br />
:I followed [http://lists.gnu.org/archive/html/grub-devel/2011-03/msg00051.html instructions] on the grub-devel mailing list. First you insert <br />
<br />
{{hc|/etc/default/grub|<br />
<nowiki><br />
GRUB_TERMINAL_INPUT=at_keyboard<br />
</nowiki>}}<br />
<br />
:in {{ic|/etc/default/grub}}. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)<br />
<br />
:{{bc|<nowiki><br />
$ ckbcomp si | grub-mklayout -o si.gkb<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown keycode 0x79<br />
$ sudo mv si.gkb /boot/grub/<br />
</nowiki>}}<br />
<br />
:After that you add <br />
<br />
{{hc|/etc/grub.d/40_custom|<br />
<nowiki><br />
insmod keylayouts<br />
keymap /boot/grub/si.gkb<br />
</nowiki>}}<br />
<br />
:to {{ic|/etc/grub.d/40_custom}} and finally generate new grub.cfg with<br />
<br />
:{{bc|$ sudo grub-mkconfig -o /boot/grub/grub.cfg}}<br />
<br />
:Cheers. --[[User:drevo|drevo]] 17:47, 6 January 2012 (EST)<br />
<br />
::The version of ckbcomp I got from Debian Squeeze kept giving this error:<br />
<br />
::{{bc|Unknown name $sun_t6_custom}}<br />
<br />
::The Ubuntu Precise version worked out of the box.<br />
<br />
::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.<br />
<br />
::--[[User:Schizius|Schizius]] ([[User talk:Schizius|talk]]) 18:44, 26 July 2012 (UTC)<br />
<br />
:::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.<br />
:::The clean solution is to create a new file ''/etc/grub.d/50_keymap''and put this:<br />
<br />
:::{{bc|<nowiki><br />
#!/bin/sh<br />
set -e<br />
# Include the GRUB helper library for grub-mkconfig.<br />
. /usr/share/grub/grub-mkconfig_lib<br />
KEYMAP_FILE=/boot/grub/bepo.gkb<br />
if ! prepare_grub_to_access_device "`${grub_probe} --target=device "${KEYMAP_FILE}"`"; then<br />
return 6--~~~~<br />
fi<br />
KEYMAP_FILE=$(make_system_path_relative_to_its_root "${KEYMAP_FILE}")<br />
cat <<EOF<br />
insmod keylayouts<br />
keymap "${KEYMAP_FILE}"<br />
EOF<br />
</nowiki>}}<br />
<br />
:::So that the root partition is detected, loaded, and then the file is read within that partition.<br />
<br />
:::--[[User:Glandos|Glandos]] ([[User talk:Glandos|talk]]) 08:23, 14 November 2013 (UTC)<br />
<br />
::::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)<br />
<br />
::::::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.)<br />
::::::--[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 19:30, 3 December 2014 (UTC)<br />
<br />
:::::::Reopening this talk since I've hit this issue myself... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:31, 3 August 2015 (UTC)<br />
<br />
:::::::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.<br />
:::::::[[User:Skizorutabaga|Skizorutabaga]] ([[User talk:Skizorutabaga|talk]]) 18:05, 23 July 2016 (UTC)<br />
<br />
::::::::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)<br />
<br />
:::::::: grub-kbdcomp /tmp/fr.gkb fr can also create keyboard layout for at_keyboard<br />
::::::::Note that at_keyboard does not always work. If at_keyboard freeze your system, you may have to use use usb_keyboard or console, so you could not use your layout...<br />
::::::::cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741464<br />
::::::::{{unsigned|04:11, 29 July 2017|Ryuta}}<br />
<br />
== grub standalone ==<br />
<br />
two things:<br />
<br />
<s>1- I think the switch<br />
--fonts="unicode"<br />
have to be removed since it is already the default behaviour<br />
(source: man grub-mkstandalone)<br />
<br />
2- before executing the command `grub-mkstandalone ...`, create the directory in your ''esp'' (e.g. /boot/EFI)<br />
otherwise it will fail<br />
<br />
--[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 09:34, 9 April 2016 (UTC)<br />
</s><br />
'''done!''' --[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 17:28, 8 February 2017 (UTC)<br />
<br />
== Grub Shell normal linux booting ==<br />
<br />
A little improvement in GRUB Shell secction.<br />
When it is described the following example in [[GRUB#Using_the_rescue_console]]<br />
<br />
----<br />
<br />
An example, booting Arch Linux:<br />
<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition (e.g. when using EFI), again change the lines accordingly: <br />
{{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.}}<br />
<br />
set root=(hd0,5)<br />
linux (hdX,Y)/vmlinuz-linux root=/dev/sda6<br />
initrd (hdX,Y)/initramfs-linux.img<br />
boot<br />
----<br />
<br />
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.<br />
Can someone explain it better? Thank you.<br />
<br />
[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 17:54, 13 August 2016 (UTC)<br />
<br />
: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.<br />
:[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 19:34, 13 August 2016 (UTC)<br />
<br />
<br />
:: 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.<br />
::[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 19:47, 13 August 2016 (UTC)<br />
<br />
== De-duplication of section header ==<br />
<br />
ATM there is a duplicate header anchor:<br />
* "Installation" links to the installation procedure for BIOS.<br />
* "Installation" &rarr; "Installation_2" links to the installation procedure for UEFI.<br />
After some chat in IRC #archlinux-wiki, I am changing the second header from "Installation" to "Install", so to avoid this duplication of headers.<br />
<br />
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.<br />
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.<br />
<br />
Examples of "external links" I am thinking about are:<br />
* Current / recent forum posts with links to the particular header / section.<br />
* Current / recent email threads / discussions with links to the particular header / section.<br />
* Other current / recent / relevant places / pages / sites with links to the particular header / section.<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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)<br />
<br />
:What exactly was wrong with the duplicate header? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:14, 6 March 2017 (UTC)<br />
<br />
:: 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.<br />
:: 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).<br />
:: 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)<br />
<br />
:::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)<br />
<br />
::::Just in case and FWIW, for the very basic info about the matter, see https://en.wikipedia.org/wiki/Help:Link#Duplicate_section_names <br />
::::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.<br />
::::Some editors don't even bother to summarize their editions, some of which are not always "the right thing to do".<br />
::::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)<br />
<br />
:::::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)<br />
<br />
::::::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.<br />
::::::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)<br />
<br />
:::::::>"Possibly I should not even care to edit at all"<br />
:::::::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?<br />
:::::::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.<br />
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:29, 8 March 2017 (UTC)<br />
<br />
::::::::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.<br />
::::::::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:<br />
*even more external links could be potentially affected;<br />
*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);<br />
*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.<br />
::::::::Now, if ("Install on BIOS" and) "Install on UEFI" is/are acceptable &mdash; they are to me &mdash; please go ahead.<br />
::::::::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)<br />
<br />
:::::::::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.<br />
:::::::::>"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."<br />
:::::::::You are right about this, in that case I would have simply reverted the renaming instead of joining this discussion.<br />
:::::::::>"leaving a temporal manual anchor also for the first header would be a plus"<br />
:::::::::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?<br />
:::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:50, 8 March 2017 (UTC)<br />
<br />
::::::::::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)<br />
<br />
== Dual Booting Windows. ==<br />
<br />
In the section on dual booting windows there is a section giving instructions for people booting BIOS-MBR <br />
<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
}<br />
}}<br />
<br />
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.<br />
<br />
{{unsigned|18:46, 23 May 2017|Theholyduck}}<br />
<br />
: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?<br />
<br />
:[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)<br />
<br />
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.<br />
<br />
[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)<br />
<br />
:I'm chainloading too, tested the "normal" method to no avail when i got some problems installing GRUB. I would like to add, if one's machine is eqipped with an UEFI firmware, and the chosen partition table is MBR, before running through the installation it's better to check the boot preferences and/or select the proper USB drive method to boot, since UEFI boot manager may have a higher priority and "corrupt" the bootloader installation. Also, in this case, when booting an USB Archiso live one should be good-to-go if the coloured Arch Linux boot menu appears (instead of a minimal black screen/white font boot menu with some UEFI options). Forgetting or ignoring to check this before installing and configuring GRUB, lead to the result that Windows (in my case, 8.1) won't be booted (even after adding a proper 40_custom configuration) nor os-prober will be able to find it. Finally, as @Alchemek may guess, even in this case Windows needs to be booted by chainloading its boot manager. Documentation about this seems missing/scarce due to the singularity of the case, but i think adding it to the Wiki should do no harm.<br />
[[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 20:37, 25 October 2017 (UTC)Lo1</div>Lo1https://wiki.archlinux.org/index.php?title=Talk:GRUB&diff=494073Talk:GRUB2017-10-25T20:37:25Z<p>Lo1: hint for enrichening of the wiki</p>
<hr />
<div>== Alpha sorting for kernel names without versions ==<br />
<br />
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:<br />
<br />
* https://savannah.gnu.org/bugs/index.php?42597<br />
<br />
Forum discussion w/patch:<br />
<br />
* https://bbs.archlinux.org/viewtopic.php?pid=1428523<br />
<br />
: [//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)<br />
<br />
::What is the current sate of this issue? --[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 10:56, 6 December 2014 (UTC)<br />
<br />
:::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)<br />
<br />
== Manually generate grub.cfg ==<br />
<br />
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].<br />
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)<br />
: I don't see a problem with this.<br />
: 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.'''''<br />
: 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)<br />
<br />
::+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)<br />
<br />
::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. <br />
::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)<br />
<br />
:::I agree with [[User:Indigo|Indigo]]. -- [[User:6arms1leg|6arms1leg]] ([[User talk:6arms1leg|talk]]) 12:48, 28 June 2015 (UTC)<br />
<br />
::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.<br />
::As to clarity, most people just run "grub-mkconfig" without understanding the process at hand, and as such, have difficulties when problems arise.<br />
::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)<br />
<br />
== Custom keyboard layout ==<br />
<br />
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.<br />
<br />
Here's how I made things work:<br />
<br />
sudo mkdir /boot/grub/layouts<br />
ckbcomp it |sudo grub-mklayout -o /boot/grub/layouts/it.gkb<br />
<br />
Then, I manually edited {{ic|/boot/grub/grub.cfg}}, adding the following lines:<br />
<br />
{{hc|/boot/grub/grub.cfg|<br />
<nowiki><br />
terminal_input at_keyboard<br />
keymap it<br />
</nowiki>}}<br />
<br />
This worked for me, but as of now, i think it's a very dirty method. Is there some support for keyboard layouts within {{ic|/etc/default/grub}}?<br />
<br />
Cheers. --[[User:Hilinus|Hilinus]] 12:50, 26 December 2011 (EST)<br />
<br />
:I followed [http://lists.gnu.org/archive/html/grub-devel/2011-03/msg00051.html instructions] on the grub-devel mailing list. First you insert <br />
<br />
{{hc|/etc/default/grub|<br />
<nowiki><br />
GRUB_TERMINAL_INPUT=at_keyboard<br />
</nowiki>}}<br />
<br />
:in {{ic|/etc/default/grub}}. Then you get ckbcomp Perl script from Ubuntu or Debian and execute (for Slovene layout)<br />
<br />
:{{bc|<nowiki><br />
$ ckbcomp si | grub-mklayout -o si.gkb<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown key KP_Comma<br />
Unknown keycode 0x79<br />
$ sudo mv si.gkb /boot/grub/<br />
</nowiki>}}<br />
<br />
:After that you add <br />
<br />
{{hc|/etc/grub.d/40_custom|<br />
<nowiki><br />
insmod keylayouts<br />
keymap /boot/grub/si.gkb<br />
</nowiki>}}<br />
<br />
:to {{ic|/etc/grub.d/40_custom}} and finally generate new grub.cfg with<br />
<br />
:{{bc|$ sudo grub-mkconfig -o /boot/grub/grub.cfg}}<br />
<br />
:Cheers. --[[User:drevo|drevo]] 17:47, 6 January 2012 (EST)<br />
<br />
::The version of ckbcomp I got from Debian Squeeze kept giving this error:<br />
<br />
::{{bc|Unknown name $sun_t6_custom}}<br />
<br />
::The Ubuntu Precise version worked out of the box.<br />
<br />
::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.<br />
<br />
::--[[User:Schizius|Schizius]] ([[User talk:Schizius|talk]]) 18:44, 26 July 2012 (UTC)<br />
<br />
:::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.<br />
:::The clean solution is to create a new file ''/etc/grub.d/50_keymap''and put this:<br />
<br />
:::{{bc|<nowiki><br />
#!/bin/sh<br />
set -e<br />
# Include the GRUB helper library for grub-mkconfig.<br />
. /usr/share/grub/grub-mkconfig_lib<br />
KEYMAP_FILE=/boot/grub/bepo.gkb<br />
if ! prepare_grub_to_access_device "`${grub_probe} --target=device "${KEYMAP_FILE}"`"; then<br />
return 6--~~~~<br />
fi<br />
KEYMAP_FILE=$(make_system_path_relative_to_its_root "${KEYMAP_FILE}")<br />
cat <<EOF<br />
insmod keylayouts<br />
keymap "${KEYMAP_FILE}"<br />
EOF<br />
</nowiki>}}<br />
<br />
:::So that the root partition is detected, loaded, and then the file is read within that partition.<br />
<br />
:::--[[User:Glandos|Glandos]] ([[User talk:Glandos|talk]]) 08:23, 14 November 2013 (UTC)<br />
<br />
::::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)<br />
<br />
::::::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.)<br />
::::::--[[User:Stevenmw|Stevenmw]] ([[User talk:Stevenmw|talk]]) 19:30, 3 December 2014 (UTC)<br />
<br />
:::::::Reopening this talk since I've hit this issue myself... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:31, 3 August 2015 (UTC)<br />
<br />
:::::::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.<br />
:::::::[[User:Skizorutabaga|Skizorutabaga]] ([[User talk:Skizorutabaga|talk]]) 18:05, 23 July 2016 (UTC)<br />
<br />
::::::::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)<br />
<br />
:::::::: grub-kbdcomp /tmp/fr.gkb fr can also create keyboard layout for at_keyboard<br />
::::::::Note that at_keyboard does not always work. If at_keyboard freeze your system, you may have to use use usb_keyboard or console, so you could not use your layout...<br />
::::::::cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741464<br />
::::::::{{unsigned|04:11, 29 July 2017|Ryuta}}<br />
<br />
== grub standalone ==<br />
<br />
two things:<br />
<br />
<s>1- I think the switch<br />
--fonts="unicode"<br />
have to be removed since it is already the default behaviour<br />
(source: man grub-mkstandalone)<br />
<br />
2- before executing the command `grub-mkstandalone ...`, create the directory in your ''esp'' (e.g. /boot/EFI)<br />
otherwise it will fail<br />
<br />
--[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 09:34, 9 April 2016 (UTC)<br />
</s><br />
'''done!''' --[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 17:28, 8 February 2017 (UTC)<br />
<br />
== Grub Shell normal linux booting ==<br />
<br />
A little improvement in GRUB Shell secction.<br />
When it is described the following example in [[GRUB#Using_the_rescue_console]]<br />
<br />
----<br />
<br />
An example, booting Arch Linux:<br />
<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition (e.g. when using EFI), again change the lines accordingly: <br />
{{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.}}<br />
<br />
set root=(hd0,5)<br />
linux (hdX,Y)/vmlinuz-linux root=/dev/sda6<br />
initrd (hdX,Y)/initramfs-linux.img<br />
boot<br />
----<br />
<br />
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.<br />
Can someone explain it better? Thank you.<br />
<br />
[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 17:54, 13 August 2016 (UTC)<br />
<br />
: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.<br />
:[[User:Silverhammermba|Silverhammermba]] ([[User talk:Silverhammermba|talk]]) 19:34, 13 August 2016 (UTC)<br />
<br />
<br />
:: 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.<br />
::[[User:Cmolina|Cmolina]] ([[User talk:Cmolina|talk]]) 19:47, 13 August 2016 (UTC)<br />
<br />
== De-duplication of section header ==<br />
<br />
ATM there is a duplicate header anchor:<br />
* "Installation" links to the installation procedure for BIOS.<br />
* "Installation" &rarr; "Installation_2" links to the installation procedure for UEFI.<br />
After some chat in IRC #archlinux-wiki, I am changing the second header from "Installation" to "Install", so to avoid this duplication of headers.<br />
<br />
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.<br />
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.<br />
<br />
Examples of "external links" I am thinking about are:<br />
* Current / recent forum posts with links to the particular header / section.<br />
* Current / recent email threads / discussions with links to the particular header / section.<br />
* Other current / recent / relevant places / pages / sites with links to the particular header / section.<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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)<br />
<br />
:What exactly was wrong with the duplicate header? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:14, 6 March 2017 (UTC)<br />
<br />
:: 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.<br />
:: 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).<br />
:: 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)<br />
<br />
:::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)<br />
<br />
::::Just in case and FWIW, for the very basic info about the matter, see https://en.wikipedia.org/wiki/Help:Link#Duplicate_section_names <br />
::::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.<br />
::::Some editors don't even bother to summarize their editions, some of which are not always "the right thing to do".<br />
::::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)<br />
<br />
:::::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)<br />
<br />
::::::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.<br />
::::::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)<br />
<br />
:::::::>"Possibly I should not even care to edit at all"<br />
:::::::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?<br />
:::::::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.<br />
:::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:29, 8 March 2017 (UTC)<br />
<br />
::::::::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.<br />
::::::::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:<br />
*even more external links could be potentially affected;<br />
*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);<br />
*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.<br />
::::::::Now, if ("Install on BIOS" and) "Install on UEFI" is/are acceptable &mdash; they are to me &mdash; please go ahead.<br />
::::::::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)<br />
<br />
:::::::::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.<br />
:::::::::>"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."<br />
:::::::::You are right about this, in that case I would have simply reverted the renaming instead of joining this discussion.<br />
:::::::::>"leaving a temporal manual anchor also for the first header would be a plus"<br />
:::::::::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?<br />
:::::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:50, 8 March 2017 (UTC)<br />
<br />
::::::::::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)<br />
<br />
== Dual Booting Windows. ==<br />
<br />
In the section on dual booting windows there is a section giving instructions for people booting BIOS-MBR <br />
<br />
<br />
{{bc|1=<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
}<br />
}}<br />
<br />
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.<br />
<br />
{{unsigned|18:46, 23 May 2017|Theholyduck}}<br />
<br />
: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?<br />
<br />
:[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)<br />
<br />
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.<br />
<br />
[[User:Alchemek|Alchemek]] ([[User talk:Alchemek|talk]]) 17:07, 12 June 2017 (UTC)<br />
<br />
:I'm chainloading too, tested the "normal" method to no avail when i got some problems installing GRUB. I would like to add, if one's machine is eqipped with an UEFI firmware, and the chosen partition table is MBR, before running through the installation it's better to check the boot preferences and/or select the proper USB drive method to boot, since UEFI boot manager may have a higher priority and "corrupt" the bootloader installation. Also, in this case, when booting an USB Archiso live one should be good-to-go if the coloured Arch Linux boot menu appears (instead of a minimal black screen/white font boot menu with some UEFI options). Forgetting or ignoring to check this before installing and configuring GRUB, lead to the result that Windows (in my case, 8.1) won't be booted (even after adding a proper 40_custom configuration) nor os-prober will be able to find it. Finally, as @Alchemek may guess, even in this case Windows needs to be booted by chainloading its boot manager. Documentation about this seems missing/scarce due to the singularity of the case, but i think adding it to the Wiki should do no harm.<br />
[[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 20:37, 25 October 2017 (UTC)Lo1</div>Lo1https://wiki.archlinux.org/index.php?title=Talk:Getting_and_installing_Arch&diff=494066Talk:Getting and installing Arch2017-10-25T18:02:13Z<p>Lo1: typo</p>
<hr />
<div>== <s>RAID 5</s> ==<br />
<br />
I'd like to add an install guide for installation to USB key /boot and RAID5 /root. How can I go about doing that?<br />
<br />
I'd be happy to create a page and send the link to someone for linking into the general "How To" area.<br />
<br />
Thanks! {{Unsigned|20:10, 2 September 2009|TomB17}}<br />
<br />
== Checksums/Windows ==<br />
<br />
We removed checksums with [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=366400&oldid=366378]; concerning the last argument, it seems you can use ''powershell'' for checksums on Windows, see [https://docs.fedoraproject.org/en-US/Fedora/22/html/Installation_Guide/sect-verifying-images.html Fedora Installation]. A possible candidate for the See also section, then again Fedora uses a different signing mechanism (the CHECKSUM file is signed, instead of the ISO). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:31, 15 October 2015 (UTC)<br />
<br />
:Um yeah, at Fedora they sign the checksums, so that powershell "script" isn't gonna work for us, hence linking to it from See also wouldn't be very helpful for a Windows user. The script shouldn't be hard to adapt though, it should be enough to tell to replace "$expected_checksum" with a paste of the checksum from our download page, also changing the function to either MD5 or SHA1 because we don't provide the SHA256 currently. I don't know if it's worth to expand [[:Category:Getting and installing Arch#Verify signature]] in this direction. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:36, 16 October 2015 (UTC)<br />
<br />
::Alternatively, we could link to [https://www.gpg4win.org/ gpg4win] and (for OSX) [https://gpgtools.org/ gpgtools] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:35, 1 August 2016 (UTC)<br />
<br />
== MBR+EFI multi boot ==<br />
<br />
Under the section "Installation methods", there are some useful notes intended for new arch linux users. I'd like to add :<br />
<br />
''If you opt for a multi boot installation using MBR partition table but your PC is UEFI-enabled, remember to boot the USB live in legacy mode to prevent issues with the bootloader.''<br />
<br />
As suggested, this note may be too specific and belongs to [[Unified_Extensible_Firmware_Interface]], still I think it's better to add it in this category anyway, since other notes concern how to boot the live usb properly and are useful for newbies (plus, that reminder would have personally saved me some hard times trying to get a bootloader properly working and [[Installation_guide]] wasn't helpful to find proper documentation). <br />
I strongly recommend to specify it in non-specialized wiki. You got any suggestion to make this reminder more appropriate? [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 13:59, 2 October 2017 (UTC)lo1<br />
<br />
:What is the bootloader that you talk about? Maybe the info belongs on its page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:13, 2 October 2017 (UTC)<br />
<br />
::I'm talking about [[GRUB]] which, as you can see, assumes your system is already well installed and functional for you to install a bootloader. However, I guess it's possible that this doesn't concern every grub installation, hence scarsity of documentation. [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 15:01, 2 October 2017 (UTC)lo1<br />
<br />
:::The [[GRUB#UEFI_systems]] already contains this note: "When installing to use UEFI it is important to start the install with your machine in UEFI mode. The Arch Linux install media must be UEFI bootable." which is very related to your problem. Considering that GRUB is the only [[boot loader]] that supports both BIOS and UEFI systems, I'd say that info really does not belong anywhere else.<br />
:::Anyway, what exactly do you mean by "multi boot installation"?<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:12, 2 October 2017 (UTC)<br />
::::Right about that, just it doesn't explain that actually pressing a few buttons before getting started may prevent real headaches. I wrote about it in the forum [https://bbs.archlinux.org/viewtopic.php?id=230258]. By "multi boot" i meant dual boot, sorry for my poor writing. Editing after some time, the reason i wanted to add that note is not intended for those who want to install using UEFI, but for those who may consider the option to use a MBR even if their machine has a UEFI firmware. [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 15:21, 2 October 2017 (UTC)lo1</div>Lo1https://wiki.archlinux.org/index.php?title=Talk:Getting_and_installing_Arch&diff=494065Talk:Getting and installing Arch2017-10-25T18:01:34Z<p>Lo1: edit my own addition for specification</p>
<hr />
<div>== <s>RAID 5</s> ==<br />
<br />
I'd like to add an install guide for installation to USB key /boot and RAID5 /root. How can I go about doing that?<br />
<br />
I'd be happy to create a page and send the link to someone for linking into the general "How To" area.<br />
<br />
Thanks! {{Unsigned|20:10, 2 September 2009|TomB17}}<br />
<br />
== Checksums/Windows ==<br />
<br />
We removed checksums with [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=366400&oldid=366378]; concerning the last argument, it seems you can use ''powershell'' for checksums on Windows, see [https://docs.fedoraproject.org/en-US/Fedora/22/html/Installation_Guide/sect-verifying-images.html Fedora Installation]. A possible candidate for the See also section, then again Fedora uses a different signing mechanism (the CHECKSUM file is signed, instead of the ISO). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:31, 15 October 2015 (UTC)<br />
<br />
:Um yeah, at Fedora they sign the checksums, so that powershell "script" isn't gonna work for us, hence linking to it from See also wouldn't be very helpful for a Windows user. The script shouldn't be hard to adapt though, it should be enough to tell to replace "$expected_checksum" with a paste of the checksum from our download page, also changing the function to either MD5 or SHA1 because we don't provide the SHA256 currently. I don't know if it's worth to expand [[:Category:Getting and installing Arch#Verify signature]] in this direction. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:36, 16 October 2015 (UTC)<br />
<br />
::Alternatively, we could link to [https://www.gpg4win.org/ gpg4win] and (for OSX) [https://gpgtools.org/ gpgtools] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:35, 1 August 2016 (UTC)<br />
<br />
== MBR+EFI multi boot ==<br />
<br />
Under the section "Installation methods", there are some useful notes intended for new arch linux users. I'd like to add :<br />
<br />
''If you opt for a multi boot installation using MBR partition table but your PC is UEFI-enabled, remember to boot the USB live in legacy mode to prevent issues with the bootloader.''<br />
<br />
As suggested, this note may be too specific and belongs to [[Unified_Extensible_Firmware_Interface]], still I think it's better to add it in this category anyway, since other notes concern how to boot the live usb properly and are useful for newbies (plus, that reminder would have personally saved me some hard times trying to get a bootloader properly working and [[Installation_guide]] wasn't helpful to find proper documentation). <br />
I strongly recommend to specify it in non-specialized wiki. You got any suggestion to make this reminder more appropriate? [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 13:59, 2 October 2017 (UTC)lo1<br />
<br />
:What is the bootloader that you talk about? Maybe the info belongs on its page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:13, 2 October 2017 (UTC)<br />
<br />
::I'm talking about [[GRUB]] which, as you can see, assumes your system is already well installed and functional for you to install a bootloader. However, I guess it's possible that this doesn't concern every grub installation, hence scarsity of documentation. [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 15:01, 2 October 2017 (UTC)lo1<br />
<br />
:::The [[GRUB#UEFI_systems]] already contains this note: "When installing to use UEFI it is important to start the install with your machine in UEFI mode. The Arch Linux install media must be UEFI bootable." which is very related to your problem. Considering that GRUB is the only [[boot loader]] that supports both BIOS and UEFI systems, I'd say that info really does not belong anywhere else.<br />
:::Anyway, what exactly do you mean by "multi boot installation"?<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:12, 2 October 2017 (UTC)<br />
::::Right about that, just it doesn't explain that actually pressing a few buttons before getting started may prevent real headaches. I wrote about it in the forum [https://bbs.archlinux.org/viewtopic.php?id=230258]. By "multi boot" i meant dual boot, sorry for my poor writing. Editing after some time, the reason i wanted to add that note is not intended for those who want to install use UEFI, but for those who may consider the option to use a MBR even if their machine has a UEFI firmware. [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 15:21, 2 October 2017 (UTC)lo1</div>Lo1https://wiki.archlinux.org/index.php?title=Talk:GNS3&diff=493939Talk:GNS32017-10-23T21:28:41Z<p>Lo1: asking for opinion about making the page richer in content</p>
<hr />
<div><br />
== VPCS ==<br />
Usually, a basic GNS3 installation is vpcs enabled, but binaries need to be downloaded. Should i add some reference in the main page?<br />
<br />
== Known Issues ==<br />
GNS 2.0.3 has this known issue: the server won't stop once the gui is closed, a popup appears after a while asking if one would like to kill it. We could create a Know Issues category for this and any other notes.<br />
<br />
[[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 21:28, 23 October 2017 (UTC)Lo1</div>Lo1https://wiki.archlinux.org/index.php?title=Talk:Getting_and_installing_Arch&diff=492186Talk:Getting and installing Arch2017-10-02T15:21:50Z<p>Lo1: /* MBR+EFI multi boot */</p>
<hr />
<div>== <s>RAID 5</s> ==<br />
<br />
I'd like to add an install guide for installation to USB key /boot and RAID5 /root. How can I go about doing that?<br />
<br />
I'd be happy to create a page and send the link to someone for linking into the general "How To" area.<br />
<br />
Thanks! {{Unsigned|20:10, 2 September 2009|TomB17}}<br />
<br />
== Checksums/Windows ==<br />
<br />
We removed checksums with [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=366400&oldid=366378]; concerning the last argument, it seems you can use ''powershell'' for checksums on Windows, see [https://docs.fedoraproject.org/en-US/Fedora/22/html/Installation_Guide/sect-verifying-images.html Fedora Installation]. A possible candidate for the See also section, then again Fedora uses a different signing mechanism (the CHECKSUM file is signed, instead of the ISO). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:31, 15 October 2015 (UTC)<br />
<br />
:Um yeah, at Fedora they sign the checksums, so that powershell "script" isn't gonna work for us, hence linking to it from See also wouldn't be very helpful for a Windows user. The script shouldn't be hard to adapt though, it should be enough to tell to replace "$expected_checksum" with a paste of the checksum from our download page, also changing the function to either MD5 or SHA1 because we don't provide the SHA256 currently. I don't know if it's worth to expand [[:Category:Getting and installing Arch#Verify signature]] in this direction. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:36, 16 October 2015 (UTC)<br />
<br />
::Alternatively, we could link to [https://www.gpg4win.org/ gpg4win] and (for OSX) [https://gpgtools.org/ gpgtools] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:35, 1 August 2016 (UTC)<br />
<br />
== MBR+EFI multi boot ==<br />
<br />
Under the section "Installation methods", there are some useful notes intended for new arch linux users. I'd like to add :<br />
<br />
''If you opt for a multi boot installation using MBR partition table but your PC is UEFI-enabled, remember to boot the USB live in legacy mode to prevent issues with the bootloader.''<br />
<br />
As suggested, this note may be too specific and belongs to [[Unified_Extensible_Firmware_Interface]], still I think it's better to add it in this category anyway, since other notes concern how to boot the live usb properly and are useful for newbies (plus, that reminder would have personally saved me some hard times trying to get a bootloader properly working and [[Installation_guide]] wasn't helpful to find proper documentation). <br />
I strongly recommend to specify it in non-specialized wiki. You got any suggestion to make this reminder more appropriate? [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 13:59, 2 October 2017 (UTC)lo1<br />
<br />
:What is the bootloader that you talk about? Maybe the info belongs on its page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:13, 2 October 2017 (UTC)<br />
<br />
::I'm talking about [[GRUB]] which, as you can see, assumes your system is already well installed and functional for you to install a bootloader. However, I guess it's possible that this doesn't concern every grub installation, hence scarsity of documentation. [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 15:01, 2 October 2017 (UTC)lo1<br />
<br />
:::The [[GRUB#UEFI_systems]] already contains this note: "When installing to use UEFI it is important to start the install with your machine in UEFI mode. The Arch Linux install media must be UEFI bootable." which is very related to your problem. Considering that GRUB is the only [[boot loader]] that supports both BIOS and UEFI systems, I'd say that info really does not belong anywhere else.<br />
:::Anyway, what exactly do you mean by "multi boot installation"?<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:12, 2 October 2017 (UTC)<br />
::::Right about that, just it doesn't explain that actually pressing a few buttons before getting started may prevent real headaches. I wrote about it in the forum [https://bbs.archlinux.org/viewtopic.php?id=230258]. By "multi boot" i meant dual boot, sorry for my poor writing. [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 15:21, 2 October 2017 (UTC)lo1</div>Lo1https://wiki.archlinux.org/index.php?title=Talk:Getting_and_installing_Arch&diff=492182Talk:Getting and installing Arch2017-10-02T15:04:56Z<p>Lo1: edit for a mistype</p>
<hr />
<div>== <s>RAID 5</s> ==<br />
<br />
I'd like to add an install guide for installation to USB key /boot and RAID5 /root. How can I go about doing that?<br />
<br />
I'd be happy to create a page and send the link to someone for linking into the general "How To" area.<br />
<br />
Thanks! {{Unsigned|20:10, 2 September 2009|TomB17}}<br />
<br />
== Checksums/Windows ==<br />
<br />
We removed checksums with [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=366400&oldid=366378]; concerning the last argument, it seems you can use ''powershell'' for checksums on Windows, see [https://docs.fedoraproject.org/en-US/Fedora/22/html/Installation_Guide/sect-verifying-images.html Fedora Installation]. A possible candidate for the See also section, then again Fedora uses a different signing mechanism (the CHECKSUM file is signed, instead of the ISO). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:31, 15 October 2015 (UTC)<br />
<br />
:Um yeah, at Fedora they sign the checksums, so that powershell "script" isn't gonna work for us, hence linking to it from See also wouldn't be very helpful for a Windows user. The script shouldn't be hard to adapt though, it should be enough to tell to replace "$expected_checksum" with a paste of the checksum from our download page, also changing the function to either MD5 or SHA1 because we don't provide the SHA256 currently. I don't know if it's worth to expand [[:Category:Getting and installing Arch#Verify signature]] in this direction. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:36, 16 October 2015 (UTC)<br />
<br />
::Alternatively, we could link to [https://www.gpg4win.org/ gpg4win] and (for OSX) [https://gpgtools.org/ gpgtools] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:35, 1 August 2016 (UTC)<br />
<br />
== MBR+EFI multi boot ==<br />
<br />
Under the section "Installation methods", there are some useful notes intended for new arch linux users. I'd like to add :<br />
<br />
''If you opt for a multi boot installation using MBR partition table but your PC is UEFI-enabled, remember to boot the USB live in legacy mode to prevent issues with the bootloader.''<br />
<br />
As suggested, this note may be too specific and belongs to [[Unified_Extensible_Firmware_Interface]], still I think it's better to add it in this category anyway, since other notes concern how to boot the live usb properly and are useful for newbies (plus, that reminder would have personally saved me some hard times trying to get a bootloader properly working and [[Installation_guide]] wasn't helpful to find proper documentation). <br />
I strongly recommend to specify it in non-specialized wiki. You got any suggestion to make this reminder more appropriate? [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 13:59, 2 October 2017 (UTC)lo1<br />
<br />
:What is the bootloader that you talk about? Maybe the info belongs on its page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:13, 2 October 2017 (UTC)<br />
<br />
::I'm talking about [[GRUB]] which, as you can see, assumes your system is already well installed and functional for you to install a bootloader. However, I guess it's possible that this doesn't concern every grub installation, hence scarsity of documentation. [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 15:01, 2 October 2017 (UTC)lo1</div>Lo1https://wiki.archlinux.org/index.php?title=Talk:Getting_and_installing_Arch&diff=492179Talk:Getting and installing Arch2017-10-02T15:01:58Z<p>Lo1: answered to discussion</p>
<hr />
<div>== <s>RAID 5</s> ==<br />
<br />
I'd like to add an install guide for installation to USB key /boot and RAID5 /root. How can I go about doing that?<br />
<br />
I'd be happy to create a page and send the link to someone for linking into the general "How To" area.<br />
<br />
Thanks! {{Unsigned|20:10, 2 September 2009|TomB17}}<br />
<br />
== Checksums/Windows ==<br />
<br />
We removed checksums with [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=366400&oldid=366378]; concerning the last argument, it seems you can use ''powershell'' for checksums on Windows, see [https://docs.fedoraproject.org/en-US/Fedora/22/html/Installation_Guide/sect-verifying-images.html Fedora Installation]. A possible candidate for the See also section, then again Fedora uses a different signing mechanism (the CHECKSUM file is signed, instead of the ISO). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:31, 15 October 2015 (UTC)<br />
<br />
:Um yeah, at Fedora they sign the checksums, so that powershell "script" isn't gonna work for us, hence linking to it from See also wouldn't be very helpful for a Windows user. The script shouldn't be hard to adapt though, it should be enough to tell to replace "$expected_checksum" with a paste of the checksum from our download page, also changing the function to either MD5 or SHA1 because we don't provide the SHA256 currently. I don't know if it's worth to expand [[:Category:Getting and installing Arch#Verify signature]] in this direction. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:36, 16 October 2015 (UTC)<br />
<br />
::Alternatively, we could link to [https://www.gpg4win.org/ gpg4win] and (for OSX) [https://gpgtools.org/ gpgtools] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:35, 1 August 2016 (UTC)<br />
<br />
== MBR+EFI multi boot ==<br />
<br />
Under the section "Installation methods", there are some useful notes intended for new arch linux users. I'd like to add :<br />
<br />
''If you opt for a multi boot installation using MBR partition table but your PC is UEFI-enabled, remember to boot the USB live in legacy mode to prevent issues with the bootloader.''<br />
<br />
As suggested, this note may be too specific and belongs to [[Unified_Extensible_Firmware_Interface]], still I think it's better to add it in this category anyway, since other notes concern how to boot the live usb properly and are useful for newbies (plus, that reminder would have personally saved me some hard times trying to get a bootloader properly working and [[Installation_guide]] wasn't helpful to find proper documentation). <br />
I strongly recommend to specify it in non-specialized wiki. You got any suggestion to make this reminder more appropriate? [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 13:59, 2 October 2017 (UTC)lo1<br />
<br />
:What is the bootloader that you talk about? Maybe the info belongs on its page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:13, 2 October 2017 (UTC)<br />
<br />
::I'm talking about [[GRUB]] which, as you can see, assumes your system is already well booted and functional for you to install a bootloader. However, I guess it's possible that this doesn't concern every grub installation, hence scarsity of documentation. [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 15:01, 2 October 2017 (UTC)lo1</div>Lo1https://wiki.archlinux.org/index.php?title=Talk:Getting_and_installing_Arch&diff=492167Talk:Getting and installing Arch2017-10-02T13:59:12Z<p>Lo1: /* MBR+EFI multi boot */ new section</p>
<hr />
<div>== <s>RAID 5</s> ==<br />
<br />
I'd like to add an install guide for installation to USB key /boot and RAID5 /root. How can I go about doing that?<br />
<br />
I'd be happy to create a page and send the link to someone for linking into the general "How To" area.<br />
<br />
Thanks! {{Unsigned|20:10, 2 September 2009|TomB17}}<br />
<br />
== Checksums/Windows ==<br />
<br />
We removed checksums with [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=366400&oldid=366378]; concerning the last argument, it seems you can use ''powershell'' for checksums on Windows, see [https://docs.fedoraproject.org/en-US/Fedora/22/html/Installation_Guide/sect-verifying-images.html Fedora Installation]. A possible candidate for the See also section, then again Fedora uses a different signing mechanism (the CHECKSUM file is signed, instead of the ISO). -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:31, 15 October 2015 (UTC)<br />
<br />
:Um yeah, at Fedora they sign the checksums, so that powershell "script" isn't gonna work for us, hence linking to it from See also wouldn't be very helpful for a Windows user. The script shouldn't be hard to adapt though, it should be enough to tell to replace "$expected_checksum" with a paste of the checksum from our download page, also changing the function to either MD5 or SHA1 because we don't provide the SHA256 currently. I don't know if it's worth to expand [[:Category:Getting and installing Arch#Verify signature]] in this direction. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 08:36, 16 October 2015 (UTC)<br />
<br />
::Alternatively, we could link to [https://www.gpg4win.org/ gpg4win] and (for OSX) [https://gpgtools.org/ gpgtools] -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 21:35, 1 August 2016 (UTC)<br />
<br />
== MBR+EFI multi boot ==<br />
<br />
Under the section "Installation methods", there are some useful notes intended for new arch linux users. I'd like to add :<br />
<br />
''If you opt for a multi boot installation using MBR partition table but your PC is UEFI-enabled, remember to boot the USB live in legacy mode to prevent issues with the bootloader.''<br />
<br />
As suggested, this note may be too specific and belongs to [[Unified_Extensible_Firmware_Interface]], still I think it's better to add it in this category anyway, since other notes concern how to boot the live usb properly and are useful for newbies (plus, that reminder would have personally saved me some hard times trying to get a bootloader properly working and [[Installation_guide]] wasn't helpful to find proper documentation). <br />
I strongly recommend to specify it in non-specialized wiki. You got any suggestion to make this reminder more appropriate? [[User:Lo1|Lo1]] ([[User talk:Lo1|talk]]) 13:59, 2 October 2017 (UTC)lo1</div>Lo1https://wiki.archlinux.org/index.php?title=Getting_and_installing_Arch&diff=492151Getting and installing Arch2017-10-02T12:47:03Z<p>Lo1: added a reminder to boot the usb live in legacy mode if user want to multi boot using mbr partition scheme, this may not be automatic on a uefi desktop/laptop and may cause some undocumented issues with the bootloader</p>
<hr />
<div>[[Category:About Arch]]<br />
[[ar:Category:Getting and installing Arch]]<br />
[[bg:Category:Getting and installing Arch]]<br />
[[cs:Category:Getting and installing Arch]]<br />
[[da:Category:Getting and installing Arch]]<br />
[[el:Category:Getting and installing Arch]]<br />
[[es:Category:Getting and installing Arch]]<br />
[[hr:Category:Getting and installing Arch]]<br />
[[id:Category:Getting and installing Arch]]<br />
[[it:Category:Getting and installing Arch]]<br />
[[ja:カテゴリ:Arch の入手とインストール]]<br />
[[ko:Category:Getting and installing Arch]]<br />
[[lt:Category:Getting and installing Arch]]<br />
[[nl:Category:Getting and installing Arch]]<br />
[[pl:Category:Getting and installing Arch]]<br />
[[pt:Category:Getting and installing Arch]]<br />
[[ru:Category:Getting and installing Arch]]<br />
[[sk:Category:Getting and installing Arch]]<br />
[[sr:Category:Getting and installing Arch]]<br />
[[th:Category:Getting and installing Arch]]<br />
[[uk:Category:Getting and installing Arch]]<br />
[[zh-hans:Category:Getting and installing Arch]]<br />
[[zh-hant:Category:Getting and installing Arch]]<br />
This category contains articles about Arch Linux releases, and downloading and installing Arch Linux. <br />
<br />
The installation media and their [[GnuPG]] signatures can be acquired from the [https://archlinux.org/download/ Download] page.<br />
<br />
== Verify signature ==<br />
<br />
It is recommended to verify the image signature before use, especially when downloading from an ''HTTP mirror'', where downloads are generally prone to be intercepted to [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#explanation serve malicious images]. <br />
<br />
On a system with [[GnuPG]] installed, do this by downloading the ''PGP signature'' (under ''Checksums'') to the ISO directory, and [[GnuPG#Verify a signature|verifying]] it with {{ic|gpg --keyserver-options auto-key-retrieve --verify archlinux-<version>-x86_64.iso.sig}}.<br />
<br />
Alternatively, run {{ic|pacman-key -v archlinux-<version>-x86_64.iso.sig}} from an existing Arch Linux installation.<br />
<br />
{{Note|<br />
* The signature itself could be manipulated if it is downloaded from a mirror site, instead of from [https://archlinux.org/download/ archlinux.org] as above. In this case, ensure that the public key, which is used to decode the signature, is signed by another, trustworthy key. The {{ic|gpg}} command will output the fingerprint of the public key. <br />
* Another method to verify the authenticity of the signature is to ensure that the public key's fingerprint is identical to the key fingerprint of the [https://www.archlinux.org/people/developers/ Arch Linux developer] who signed the ISO-file. See [[Wikipedia:Public-key_cryptography]] for more information on the public-key process to authenticate keys.<br />
}}<br />
<br />
== Installation methods ==<br />
<br />
The table below offers an overview of the common ways to boot the installation media. As the installation process retrieves packages from a remote repository, these methods require an internet connection; see [[Offline installation of packages]] and [[Archiso#Installation without Internet access]] when none is available.<br />
<br />
{{Note|<br />
* Pointing the current boot device to a drive containing the Arch installation media is typically achieved by pressing a key during the [[w:Power-on self test|POST]] phase, as indicated on the splash screen. Refer to your motherboard's manual for details.<br />
* When the Arch menu appears, select ''Boot Arch Linux'' and press {{ic|Enter}} to enter the installation environment.<br />
* If you opt for a multi boot installation using MBR partition table but your PC is UEFI-enabled, remember to boot the USB live in legacy mode to prevent issues with the bootloader.<br />
* See [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams README.bootparams] for a list of [[Kernel parameters#Configuration|boot parameters]], and [https://git.archlinux.org/archiso.git/tree/configs/releng/packages.both packages.both] for a list of included packages.<br />
}}<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 />
| Install Arch next to a Windows installation.<br />
|<br />
* [[Dual boot with Windows]]<br />
|<br />
* Machine shared with Windows users<br />
* Allow to easily factory-reset a Windows-preinstalled device<br />
|}<br />
<br />
== See also ==<br />
* [https://projects.archlinux.org/archiso.git/tree/docs/README.transfer README.transfer]<br />
* [https://projects.archlinux.org/archiso.git/tree/docs/README.altbootmethods README.altbootmethods]</div>Lo1