https://wiki.archlinux.org/api.php?action=feedcontributions&user=Oliver&feedformat=atomArchWiki - User contributions [en]2024-03-29T07:11:42ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:Install_Arch_Linux_via_Docker&diff=780728Talk:Install Arch Linux via Docker2023-06-09T10:58:47Z<p>Oliver: Issue created/responded too, better place to have the discussion. The title also says 'docker' not 'podman' (though its fair wanting to use it)</p>
<hr />
<div></div>Oliverhttps://wiki.archlinux.org/index.php?title=CUPS/Printer-specific_problems&diff=771514CUPS/Printer-specific problems2023-03-07T15:14:57Z<p>Oliver: /* HPLIP */ fix formatting</p>
<hr />
<div>[[Category:Printers]]<br />
[[ja:CUPS/プリンター別の問題]]<br />
[[ru:CUPS (Русский)/Printer-specific problems]]<br />
{{Related articles start}}<br />
{{Related|CUPS}}<br />
{{Related|CUPS/Troubleshooting}}<br />
{{Related articles end}}<br />
<br />
This article contains printer or manufacturer-specific instructions for [[CUPS]].<br />
See [https://www.openprinting.org/printers OpenPrinting] if your printer is not already listed here, or if none of the listed drivers work.<br />
<br />
{{Note|If you add a printer to this list, consider contributing your entry to [https://wiki.linuxfoundation.org/openprinting/database/databaseintro OpenPrinting] - that way users of other distributions will also benefit!}}<br />
<br />
== Brother ==<br />
<br />
{{Note|Some printer models can be found in several entries because there are several packages or drivers for them.}}<br />
<br />
Drivers for several models:<br />
<br />
{|class="wikitable"<br />
! Printers<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| DCP-1510 series (DCP-1510, DCP-1510r, DCP-1511, DCP-1512, DCP-1512r, DCP-1518) || {{AUR|brother-dcp1510}} ||<br />
|-<br />
| DCP-7010, DCP-7020, DCP-7025, DCP-8060, DCP-8065DN, FAX-2820, FAX-2920, HL-2030, HL-2040, HL-2070N, HL-5240, HL-5250DN, HL-5270DN, HL-5280DW, MFC-7220, MFC-7225N, MFC-7420, MFC-7820N, MFC-8460N, MFC-8660DN, MFC-8860DN, MFC-8870DW || {{AUR|brother-cups-wrapper-laser}} ||<br />
|-<br />
| HL-4040CN, HL-4040CDN, HL-4050CDN, HL-4070CDW, MFC-9440CN, MFC-9450CDN, MFC-9840CDW, DCP-9040CN, DCP-9042CDN, DCP-9045CDN || {{AUR|brother-cups-wrapper-ac}} ||<br />
|-<br />
| DCP-1510 series, DCP-1600 series, DCP-7030, DCP-7040, DCP-7055, DCP-7055W, DCP-7060D, DCP-7065DN, DCP-7080, DCP-L2500D series, DCP-L2520D series, DCP-L2540DW series, HL-1110 series, HL-1200 series, HL-2030 series, HL-2140 series, HL-2220 series, HL-2270DW series, HL-5030 series, HL-L2300D series, HL-L2320D series, HL-L2340D series, HL-L2360D series, MFC-1910W, MFC-1919NW, MFC-7240, MFC-7360N, MFC-7365DN, MFC-7840W, Lenovo M7605D || {{AUR|brlaser}}<br />{{AUR|brlaser-git}} || Unofficial driver, may be compatible with more models<br />
|}<br />
<br />
Drivers for one model:<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| DCP-135C || {{AUR|brother-dcp135c}} ||<br />
|-<br />
| DCP-150C || {{AUR|brother-dcp150c}} ||<br />
|-<br />
| DCP-150C || {{AUR|brother-dcp150c}} ||<br />
|-<br />
| DCP-2550DW ||{{AUR|brother-dcp-l2550dw}} ||<br />
|-<br />
| DCP-B7500D || {{AUR|brother-dcpb7500d}} ||<br />
|-<br />
| DCP-L3550CDW || {{AUR|brother-dcpl3550cdw}} || Use IPP driver as described [https://aur.archlinux.org/packages/brother-dcpl3550cdw/#comment-728480 here] and [https://www.printerforums.net/threads/brother-dcp-l3550cdw.68978/ here].<br />
|-<br />
| DCP-7020 || [[foomatic]] || Or Brother's driver.<br />
|-<br />
| DCP-7030 || {{AUR|brother-dcp7030}} ||<br />
|-<br />
| DCP-7065DN || {{AUR|brother-dcp7065dn}} ||<br />
|-<br />
| DCP-9020CDW || {{AUR|brother-dcp-9020cdw}} ||<br />
|-<br />
| DCP-J515W || {{AUR|brother-dcp-j515w}} ||<br />
|-<br />
| DCP-J4110DW || {{AUR|brother-dcpj4110dw}} ||<br />
|-<br />
| DCP-J1200W || {{AUR|brother-dcpj1200w}} || "DCPJ1200W" is added automatically to cups when installing this aur package. multilib not required. SANE drivers for this model: {{AUR|brscan5}}<br />
|-<br />
| FAX-2820 || {{AUR|brother-cups-wrapper-laser}} ||<br />
|-<br />
| FAX-2840 || {{AUR|brother-fax2840}} || Or [[foomatic]] - works mostly with {{ic|hpijs-pcl5e.ppd}}. Same as the HL-2170W.<br />
|-<br />
| FAX-2940 || {{AUR|brother-fax2940}} ||<br />
|-<br />
| HL-1110 || {{AUR|brlaser-git}} || Tested and it works<br />
|-<br />
| HL-2030 || [[foomatic]] || Or {{AUR|brother-hl2030}}<br />
|-<br />
| HL-2035 || [[foomatic]] || Should be compatible with any drivers for the HL-2030.<br />
|-<br />
| HL-2040 || [[foomatic]] || Or {{AUR|brother-hl2040}}<br />
|-<br />
| HL-2130 || [[foomatic]] (using the HL-2140 driver) || Or {{Pkg|hplip}}<br />
|-<br />
| HL-2135W || {{AUR|brother-brgenml1}} ||<br />
|-<br />
| HL-2140 || [[foomatic]] || Or {{AUR|brother-hl2140}}<br />
|-<br />
| HL-2170W || [[foomatic]] || Or Brother's driver. <br />
|-<br />
| HL-2230 || [[foomatic]] || Same as HL-2170W. Select HL-2170W as the driver in CUPS admin when adding a printer.<br />
|-<br />
| HL-2250DN || {{AUR|brother-brgenml1}} || {{AUR|brother-hl2250dn}} is broken?<br />
|-<br />
| HL-2270DW || {{AUR|brother-hl2270dw}} ||<br />
|-<br />
| HL-2280DW || {{AUR|brother-hl2280dw}} ||<br />
|-<br />
| HL-3045CN || Install Brother's driver or {{AUR|brother-hl3040cn}}.||<br />
|-<br />
| HL-3140CW || {{AUR|brother-hl3140cw}} || Use IPP and Brother's driver to avoid page-shrinking and endless blank printouts<br />
|-<br />
| HL-3150CDW || {{AUR|brother-hl3150cdw}} ||<br />
|-<br />
| HL-3170CDW || {{AUR|brother-hl3170cdw}} ||<br />
|-<br />
| HL-4150CDN || {{AUR|brother-hl4150cdn}} ||<br />
|-<br />
| HL-5140 || [[foomatic]] || Or Brother's driver.<br />
|-<br />
| HL-5340 || [[foomatic]] || Using the ''Generic PCL 6/PCL XL Printer - CUPS+Gutenprint'' ({{Pkg|gutenprint}} and {{Pkg|foomatic-db-gutenprint-ppds}}). Or Brother's driver, which may result in failed prints with postscript errors.<br />
|-<br />
| HL-L2300D || {{AUR|brother-hll2300d}} || {{AUR|brlaser-git}} works better. Using the brother driver, only defaults are honored and print-specific settings are ignored.<br />
|-<br />
| HL-L2340DW || {{AUR|brother-hll2340dw}} ||<br />
|-<br />
| HL-L2350DW || {{AUR|brother-hll2350dw}} ||<br />
|-<br />
| HL-L2360DN || {{AUR|brother-hll2360d}} || Or {{AUR|brlaser-git}}<br />
|-<br />
| HL-L2360DW || {{AUR|brother-hll2360d}} || {{AUR|brlaser-git}} should works.<br />
|-<br />
| HL-L2365DW || {{AUR|brother-hll2360d}} || {{AUR|brlaser-git}} should works.<br />
|-<br />
| HL-L2380DW || {{AUR|brother-hll2380dw}} ||<br />
|-<br />
| HL-L2395DW || {{AUR|brother-hll2395dw}} || Use the {{ic|socket}} protocol as described in [[#Network printers]]<br />
|-<br />
| HL-L3230CDW || {{AUR|brother-hll3230cdw}} || Or https://github.com/splitbrain/archlinux-brother-hll3230cdw<br />
|-<br />
| HL-L3270CDW || {{AUR|brother-hll3270cdw}} || Use the {{ic|lpd}} protocol as described in [[#Network printers]].<br />
|-<br />
| HL-L5100DN || HP LaserJet Foomatic driver || This model will emulate a HP LaserJet. Use the {{ic|lpd}} protocol as described in [[#Network printers]].<br />
|-<br />
| HL-L8360CDW || {{AUR|brother-hll8360cdw-cups-bin}} ||<br />
|-<br />
| MFC-420CN || {{AUR|brother-mfc-420cn}} ||<br />
|-<br />
| MFC-440CN || {{AUR|brother-mfc-440cn}} ||<br />
|-<br />
| MFC-7360N || {{AUR|brother-mfc7360n}} || Or {{AUR|brlaser-git}}<br />
|-<br />
| MFC-7460DN || [[Gutenprint]] || Use the ''Generic PCL 6 Printer wide margin - CUPS+Gutenprint'' driver, with address {{ic|ipp://hostname-or-ip/pcl_p1}}.<br />
|-<br />
| MFC-7840W || {{AUR|brother-mfc-7840w}} || Or {{AUR|brlaser-git}}<br />
|-<br />
| MFC-9320CW || Install Brother's driver. ||<br />
|-<br />
| MFC-9332CDW || {{AUR|brother-mfc-9332cdw}} ||<br />
|-<br />
| MFC-9840CDW || [[foomatic]] || Or Brother's driver. This printer also works with the generic PCL-6 driver from the {{Pkg|gutenprint}} package. Use '''pcl_p1''' for the printer's address when using the PCL-6 driver.<br />
|-<br />
| MFC-J1300DW || {{AUR|brother-mfc-j1300dw}} || Use the {{ic|ipp}} protocol as described in [[#Network printers]].<br />
|-<br />
| MFC-J435W || {{AUR|brother-mfc-j435w}} || Use {{ic|lpd://[printer_addr]/BINARY_P1}} or {{ic|http://[printer_addr]/POSTSCRIPT_P1}} as described in the comments section of the AUR package page.<br />
|-<br />
| MFC-J470DW || {{AUR|brother-mfc-j470dw}} || Use the {{ic|ipp}} protocol as described in [[#Network printers]].<br />
|-<br />
| MFC-J4710DW || {{AUR|brother-mfc-j4710dw}} ||<br />
|-<br />
| MFC-J480DW || {{AUR|brother-mfc-j480dw}} || Use the {{ic|ipp}} protocol as described in [[#Network printers]].<br />
|-<br />
| MFC-J5520DW || {{AUR|brother-mfc-j5520dw}} ||<br />
|-<br />
| MFC-J5845DW || {{AUR|brother-mfc-j5845dw}} || Use the {{ic|ipp}} protocol as described in [[#Network printers]].<br />
|-<br />
| MFC-J5910DW || {{AUR|brother-mfc-j5910dw}} ||<br />
|-<br />
| MFC-J650DW || Install Brother's driver. ||<br />
|-<br />
| MFC-J885DW || {{AUR|brother-mfc-j885dw}} ||<br />
|-<br />
| MFC-J985DW || {{AUR|brother-mfc-j985dw}} ||<br />
|-<br />
| MFC-L2700DN || {{AUR|brother-mfc-l2700dn}} || Please look also at the comments section of the AUR package page. <br />
|-<br />
| MFC-L2700DW || {{AUR|brother-mfc-l2700dw}} || Please look also at the comments section of the AUR package page. <br />
|-<br />
| MFC-L2710DN || {{AUR|brother-mfc-l2700dn}} || Use the {{ic|ipp}} protocol as described in [[#Network printers]].<br />
|-<br />
| MFC-L2710DW || {{AUR|brother-mfc-l2710dw}} || Use the {{ic|lpd}} protocol as described in [[#Network printers]].<br />
|-<br />
| MFC-L2720DW || {{AUR|brother-mfc-l2720dw}} || Please look also at the comments section of the AUR package page. <br />
|-<br />
| MFC-L2730DW || {{AUR|brother-mfc-l2730dw}} || Please look also at the comments section of the AUR package page. <br />
|-<br />
| MFC-L2740DW || {{AUR|brother-mfc-l2740dw}} || Please look also at the comments section of the AUR package page. <br />
|-<br />
| MFC-L5800DW || {{AUR|brother-mfc-l5750dw}} || <br />
|-<br />
| MFC-L8600CDW || {{AUR|brother-mfc-l8600cdw}} || Please follow the instructions on the AUR page.<br />
|-<br />
| QL-500 || {{AUR|brother-ql500}} ||<br />
|-<br />
| QL-570 || {{AUR|brother-ql570}} ||<br />
|-<br />
| QL-580N || {{AUR|brother-ql580n}} ||<br />
|-<br />
| QL-650TD || {{AUR|brother-ql650td}} ||<br />
|-<br />
| QL-700 || {{AUR|brother-ql700}} ||<br />
|-<br />
| QL-710W || {{AUR|brother-ql710w}} ||<br />
|-<br />
| QL-720NW || {{AUR|brother-ql720nw}} ||<br />
|-<br />
| QL-1050 || {{AUR|brother-ql1050}} || <br />
|-<br />
| QL-1050N || {{AUR|brother-ql1050n}} ||<br />
|-<br />
| QL-1060 || {{AUR|brother-ql1060n}} ||<br />
|-<br />
| QL-1110NWB || {{AUR|brother-ql1110nwb}} ||<br />
|-<br />
| TD-2020 || {{AUR|brother-td2020}} ||<br />
|-<br />
| TD-2120N || {{AUR|brother-td2120n}} ||<br />
|-<br />
| TD-2130N || {{AUR|brother-td2130n}} ||<br />
|-<br />
| TD-4000 || {{AUR|brother-td4000}} ||<br />
|-<br />
| TD-4100N || {{AUR|brother-td4100n}} ||<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
=== Network printers ===<br />
<br />
For network printers, use {{ic|ipp://'''printer_ip'''/ipp/port1}} as printer address.<br />
For some older printers, this might not work. If not, try {{ic|lpd://'''printer_ip'''/BINARY_P1}} instead.<br />
<br />
Some printers use the socket protocol. For these printers, use {{ic|socket://'''printer_ip''':9100}}.<br />
For http, use {{ic|http://'''printer_ip'''/POSTSCRIPT_P1}}.<br />
<br />
=== Custom drivers ===<br />
<br />
Brother provides custom drivers on their website, either in source tarball, rpm, or deb form. [[Packaging Brother printer drivers]] covers creating [[PKGBUILD]]s from the existing RPM packages.<br />
<br />
{{Note|The source packages might be a better alternative to the rpm packages, provided they contain all the needed files.}}<br />
<br />
==== Manually installing from the RPM packages ====<br />
<br />
{{Warning|This should ideally be automated in a [[PKGBUILD]].}}<br />
<br />
[[Install]] the {{Pkg|rpmextract}} package, and extract both rpm packages using {{ic|rpmextract.sh}}. Extracting both files will create a var and a usr directory - move the contents of both directories into the corresponding root directories.<br />
<br />
Run the cups wrapper file in {{ic|/usr/local/Brother/cupswrapper}}. This should automatically install and configure your brother printer.<br />
<br />
For some of the drivers 32 bit libraries may need to be installed from [[multilib]].<br />
<br />
=== Updating the firmware ===<br />
<br />
[[Install]] {{Pkg|net-snmp}} and run:<br />
<br />
$ snmpwalk -c public $PRINTER_IP | grep -A 1 3.6.1.4.1.2435.2.4.3.99.3.1.6.1.2<br />
<br />
Or alternatively:<br />
<br />
$ snmpwalk -v 2c -c public 192.168.23.11 iso.3.6.1.4.1.2435.2.4.3.99.3.1.6.1.2<br />
<br />
At this point, you will have the relevant data to get a valid firmware download link from Brother. The file should look similar to the one below:<br />
<br />
{{hc|request.xml|<br />
<REQUESTINFO><br />
<FIRMUPDATETOOLINFO><br />
<FIRMCATEGORY>MAIN</FIRMCATEGORY><br />
<OS>LINUX</OS><br />
<INSPECTMODE>1</INSPECTMODE><br />
</FIRMUPDATETOOLINFO><br />
<br />
<FIRMUPDATEINFO><br />
<MODELINFO><br />
<SELIALNO></SELIALNO><br />
<NAME>MFC-9330CDW</NAME><br />
<SPEC>0401</SPEC><br />
<DRIVER></DRIVER><br />
<FIRMINFO><br />
<FIRM><br />
<ID>MAIN</ID><br />
<VERSION>R1506121801:4504</VERSION><br />
</FIRM><br />
<FIRM><br />
<ID>SUB1</ID><br />
<VERSION>1.07</VERSION><br />
</FIRM><br />
<FIRM><br />
<ID>SUB2</ID><br />
<VERSION>L1505291600</VERSION><br />
</FIRM><br />
</FIRMINFO><br />
</MODELINFO><br />
<DRIVERCNT>1</DRIVERCNT><br />
<LOGNO>2</LOGNO><br />
<ERRBIT></ERRBIT><br />
<NEEDRESPONSE>1</NEEDRESPONSE><br />
</FIRMUPDATEINFO><br />
</REQUESTINFO><br />
}}<br />
<br />
Post this file to Brother:<br />
<br />
$ curl -X POST -d @request.xml https://firmverup.brother.co.jp/kne_bh7_update_nt_ssl/ifax2.asmx/fileUpdate -H "Content-Type:text/xml" > response.xml<br />
<br />
In {{ic|response.xml}} you will find a {{ic|<PATH>}} tag that contains the firmware download URL. Next, download the firmware, push it to the printer, and let the printer process it. Before that is done, change the Admin password to something known, it will be used as the user to log into the FTP site (VERY bad practice, do not do this). <br />
<br />
$ wget http://update-akamai.brother.co.jp/CS/LZ4266_W.djf<br />
$ ftp $PRINTER_IP|<br />
ftp> bin<br />
ftp> hash<br />
ftp> send LZ4266_W.djf<br />
ftp> bye<br />
<br />
With that, the printer will restart, and the latest firmware will be installed and (hopefully) your printing woes will be solved.<br />
<br />
=== IPP-over-USB ===<br />
<br />
You might experience some trouble while using the USB port on certain models. <br />
<br />
Brother provides a shell script to create udev rules to prevent the use of IPP-over-USB. This might solve USB printing problems but means that you need to use the legacy LPR driver. See the [https://support.brother.com/g/b/faqend.aspx?c=us_ot&lang=en&prod=mfcl9570cdw_us_eu_as&faqid=faq00100729_000 FAQ article].<br />
<br />
== Canon ==<br />
<br />
There are many possible drivers for Canon printers. [https://gimp-print.sourceforge.net/p_Supported_Printers.php Many Canon printers] are supported by [[Gutenprint]] and {{pkg|foomatic-db-ppds}}. Some of Canon's LBP, iR, and MF printers use a driver supporting the UFR II/UFR II LT/LIPSLX protocols, [[#UFRII]] . Others use the [[#CARPS]], or [[#cnijfilter]] ({{AUR|cnijfilter2}} / {{AUR|cnijfilter2-bin}}), or [[Canon CAPT]] drivers.<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| iP4300 || rowspan="2" | [[Gutenprint]] || Or use the [https://www.turboprint.info/ TurboPrint] driver.<br />
|-<br />
| PIXMA G4000 series|| Misidentifies itself as Canon G3010 Series. Use Canon PIXMA G4000 - CUPS+Gutenprint driver instead.<br />
|-<br />
| LBP810 || rowspan="34" | [[Canon CAPT]] ||<br />
|-<br />
| LBP1120 ||<br />
|-<br />
| LBP1210 ||<br />
|-<br />
| LBP2900 ||<br />
|-<br />
| LBP3000 ||<br />
|-<br />
| LBP3010 ||<br />
|-<br />
| LBP3018 ||<br />
|-<br />
| LBP3050 ||<br />
|-<br />
| LBP3100 ||<br />
|-<br />
| LBP3108 ||<br />
|-<br />
| LBP3150 ||<br />
|-<br />
| LBP3200 ||<br />
|-<br />
| LBP3210 ||<br />
|-<br />
| LBP3250 ||<br />
|-<br />
| LBP3300 ||<br />
|-<br />
| LBP3310 ||<br />
|-<br />
| LBP3500 ||<br />
|-<br />
| LBP5000 ||<br />
|-<br />
| LBP5050 series ||<br />
|-<br />
| LBP5100 ||<br />
|-<br />
| LBP5300 ||<br />
|-<br />
| LBP6000 ||<br />
|-<br />
| LBP6018 ||<br />
|-<br />
| LBP6020 ||<br />
|-<br />
| LBP6200 ||<br />
|-<br />
| LBP6300 ||<br />
|-<br />
| LBP6300n ||<br />
|-<br />
| LBP6310dn ||<br />
|-<br />
| LBP7010C ||<br />
|-<br />
| LBP7018C ||<br />
|-<br />
| LBP7200Cdn (network mode) ||<br />
|-<br />
| LBP7200C series ||<br />
|-<br />
| LBP7210Cdn ||<br />
|-<br />
| LBP9100C ||<br />
|-<br />
| MF216n (network over ldp) || rowspan="4" | {{AUR|cndrvcups-lb-bin}} ||<br />
|-<br />
| MF635Cx ||<br />
|-<br />
| MF4720w ||<br />
|-<br />
| MF4770n ||<br />
|-<br />
| MG4200 series || {{AUR|cnijfilter-mg4200}} || Avoid the [[CUPS#Web interface|web interface]] when adding the printer as it will not find the PPD file.<br />
|-<br />
| MB2350 || rowspan="6" | {{AUR|cnijfilter2}}<br />{{AUR|cnijfilter2-bin}} ||<br />
|-<br />
| MX490 ||<br />
|-<br />
| MX492 ||<br />
|-<br />
| TR8500 series ||<br />
|-<br />
| TS202 ||<br />
|-<br />
| TS3100 series ||<br />
|-<br />
| TS8050 || Without {{AUR|cnijfilter2}} printing will fail with a filter error or you might get "Rendering Completed" and nothing will print<br />
|-<br />
| TS9020 || {{AUR|canon-ts9020}} ||<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
Some Canon printers will use a similar setup to the iP4500, so consider modifying the {{AUR|cnijfilter-ip4500}} package for other, similar printers.<br />
<br />
=== UFRII ===<br />
<br />
Many LBP, iR, and MF printers use a protocol that has had several names over the years: UFR II, UFR II LT, LIPSLX. There are multiple packages for these printers in AUR, and at least the imageCLASS MF4570dn and i-sensys MF633C are reported to only work with the older v3.70 version.<br />
<br />
{{AUR|cnrdrvcups-lb}} v 5.00: latest version built from source<br />
<br />
{{AUR|cndrvcups-lb}} 3.70 and {{AUR|cndrvcups-common-lb}} 4.10: older version built from source<br />
<br />
{{AUR|cndrvcups-lb-bin}} v3.70: uses Canon provided binaries with location/config adjustments to make them work on Arch Linux<br />
<br />
=== CARPS ===<br />
<br />
Some of Canon's printers use Canon's proprietary CARPS (''Canon Advanced Raster Printing System'') driver.<br />
[https://www.rainbow-software.org/2014/01/23/cups-driver-for-canon-carps-printers/ Rainbow Software] have managed to reverse engineer the CARPS data format and have successfully created a CARPS CUPS driver, which is available as {{AUR|carps-cups-git}}.<br />
The project's [https://github.com/ondrej-zary/carps-cups GitHub] page includes a list of working printers.<br />
<br />
=== USB over IP (BJNP) ===<br />
<br />
Some Canon printers use Canon's proprietary USB over IP BJNP protocol to communicate over the network. There is a CUPS backend for this, which is available as {{AUR|cups-bjnp}}.<br />
<br />
=== cnijfilter ===<br />
<br />
Some printers using the cnijfilter drivers support the {{ic|cnijnet}} protocol. To find the [[CUPS#Printer URI|printer URI]] run<br />
<br />
$ cnijnetprn --search auto<br />
<br />
and use the {{ic|cnijnet:/}} URI in the output.<br />
<br />
Other driver versions, as is the case for the current version of {{AUR|cnijfilter2}}, provide the {{ic|cnijlgmon3}} binary to search for available printers.<br />
<br />
{{hc|$ cnijlgmon3|output=<br />
network cnijbe2://Canon/?port=net&serial=60-12-81-A7-7D-34 "Canon MB2300 series" "Canon-MB2300-series_60-12-81-A7-7D-34"<br />
}}<br />
<br />
The printer can be added to cups using the {{ic|cnijbe2}} url and an appropriate {{ic|.ppd}} file, which should be shipped with your driver. <br />
<br />
$ lpadmin -p CustomPrinterNameMB2300 -P /usr/share/cups/model/canonmb2300.ppd -v "cnijbe2://Canon/?port=net&serial=60-12-81-A7-7D-34" -E<br />
<br />
The argument {{ic|serial}} in the cnijbe2 url corresponds to the MAC address of the printer.<br />
<br />
=== IPP Everywhere ===<br />
<br />
For recent Canon printers, like the G7000 series, it can be hard to find a valid driver. However, it is possible to use a driverless installation using IPP Everywhere.<br />
<br />
If you have installed avahi, CUPS should be able to detect your printer automatically.<br />
<br />
However, if it fails, you can always enter your printer settings manually. In CUPS web interface select {{ic|Internet Printing Protocol (ipp)}} and enter the IPP URL of the printer. Then at the driver selection screen select{{ic|Generic > {current_make_and_model} - IPP Everywhere ™}}.<br />
<br />
For the G7000 series the IPP URL is {{ic|ipp://<printer_ip>}} or {{ic|ipps://<printer_ip>}}.<br />
<br />
== Dell ==<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| 1250C<br />
| rowspan=2 | {{AUR|foo2zjs-nightly}}<br />
| rowspan=2 | The printer may also work with the [[#Phaser 6000B|Xerox Phaser 6000B driver]].<br />
|-<br />
| C1660NW<br />
|-<br />
| E515<br />
| rowspan=2 | Install [https://downloads.dell.com/FOLDER03040853M/1/Printer_E515dw_Driver_Dell_A00_LINUX.zip Dell's driver].<br />
| rowspan=2 | Both ''e515dwcupswrapper-3.2.0-1.i386.deb'' and ''e515dwlpr-3.2.0-1.i386.deb'' need to be installed. You could either write a [[PKGBUILD]], use {{AUR|debtap}}, or use {{Pkg|dpkg}} (using dpkg is not recommended as the files will not be managed by [[pacman]]). The driver works on both the x86_64 and i386 platforms, but may require [[multilib]].<br />
|-<br />
| E515dw<br />
|-<br />
| S1130n || rowspan="16" | {{aur|dell-unified-driver}} || rowspan="16" | Driver conflicts with samsung-unified-driver-printer (as the dell-unified-driver appears to be based on the Samsung one, and they create several of the same files)<br />
|-<br />
|1130<br />
|-<br />
|1133<br />
|-<br />
|1135n<br />
|-<br />
|1815<br />
|-<br />
|2145cn<br />
|-<br />
|2335dn<br />
|-<br />
|2355dn<br />
|-<br />
|5330<br />
|-<br />
|B1160<br />
|-<br />
|B1160w<br />
|-<br />
|B1165nfw<br />
|-<br />
|B1260dn<br />
|-<br />
|B1265dfw<br />
|-<br />
|B1265dnf<br />
|-<br />
|B2365dnf<br />
|-<br />
<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
== Epson ==<br />
<br />
{{AUR|epson-inkjet-printer-escpr}} and {{AUR|epson-inkjet-printer-escpr2}} are sets of drivers using the Epson Inkjet Printer Driver (ESC/P-R) for Linux.<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| AcuLaser C900 || || This printer uses Epson's driver, with a device URI of ''''usb://EPSON/AL-C900'''', and may need the pipsplus service to be running.<br />
|-<br />
| EP-50V || rowspan="4" | {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| EP-879A ||<br />
|-<br />
| EP-880A ||<br />
|-<br />
| EP-881A ||<br />
|-<br />
| ET-2700 || rowspan="2" | {{AUR|epson-inkjet-printer-escpr}} ||<br />
|-<br />
| ET-2750 ||<br />
|-<br />
| ET-3700 || rowspan="5" | {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| ET-3750 ||<br />
|-<br />
| ET-3760 ||<br />
|-<br />
| ET-4750 ||<br />
|-<br />
| ET-4760 ||<br />
|-<br />
| EW-M571T || {{AUR|epson-inkjet-printer-escpr}} ||<br />
|-<br />
| EW-M670FT || {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| L380 || rowspan="2" | {{AUR|epson-inkjet-printer-201601w}} ||<br />
|-<br />
| L382 ||<br />
|-<br />
| L3150 || rowspan="3" | {{AUR|epson-inkjet-printer-escpr}} ||<br />
|-<br />
| L4150 ||<br />
|-<br />
| L4160 ||<br />
|-<br />
| L6160 || rowspan="3" | {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| L6170 ||<br />
|-<br />
| L6190 ||<br />
|-<br />
| LP-S5000 || || This printer requires a [[#Avasys|custom driver from Avasys]].<br />
|-<br />
| PM-520 || rowspan="11" | {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| PX-M5080F ||<br />
|-<br />
| PX-M5081F ||<br />
|-<br />
| PX-M680F ||<br />
|-<br />
| PX-M7070FX ||<br />
|-<br />
| PX-M780F ||<br />
|-<br />
| PX-M781F ||<br />
|-<br />
| PX-M884F ||<br />
|-<br />
| PX-S5080 ||<br />
|-<br />
| PX-S7070X ||<br />
|-<br />
| PX-S884 ||<br />
|-<br />
| TX125 || {{AUR|epson-inkjet-printer-n10-nx127}} ||<br />
|-<br />
| WF-3620 || {{AUR|epson-inkjet-printer-escpr}} ||<br />
|-<br />
| WF-3720 || rowspan="8" | {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| WF-4720 ||<br />
|-<br />
| WF-4730 ||<br />
|-<br />
| WF-4740 ||<br />
|-<br />
| WF-7210 ||<br />
|-<br />
| WF-7710 ||<br />
|-<br />
| WF-7720 ||<br />
|-<br />
| WF-C869R ||<br />
|-<br />
| XP-205 -207 || {{AUR|epson-inkjet-printer-escpr}} ||<br />
|-<br />
| XP-446 || rowspan="2" | {{AUR|epson-inkjet-printer-escpr}} ||<br />
|-<br />
| XP-630 Series<br />
|-<br />
| XP-5100 || rowspan="4" | {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| XP-6000 ||<br />
|-<br />
| XP-8500 ||<br />
|-<br />
| XP-15000 ||<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
=== Utilities ===<br />
<br />
==== escputil ====<br />
<br />
escputil is part of the {{Pkg|gutenprint}} package, and performs some utility functions on Epson printers such as nozzle cleaning.<br />
<br />
==== mtink ====<br />
<br />
This is a printer status monitor which enables to get the remaining ink quantity, to print test patterns, to reset printer and to clean nozzle. It use an intuitive graphical user interface.<br />
<br />
==== Stylus-toolbox ====<br />
<br />
This is a GUI using escputil and cups drivers. It supports nearly all USB printer of Epson and displays ink quantity, can clean and align print heads and print test patterns.<br />
<br />
===Custom drivers===<br />
<br />
==== Avasys ====<br />
<br />
{{Warning|This section involves installing packages without [[pacman]]. These directions should ideally be automated with a [[PKGBUILD]].}}<br />
"Source" code of the driver is available on the [https://www.avasys.jp avasys website], in Japanese, however it includes a 32 bit binary which will cause problem on 64 bit system.<br />
<br />
* [[Install]] the {{Pkg|psutils}}, {{Pkg|bc}}, {{AUR|libstdc++5}} packages ({{AUR|lib32-libstdc++5}} on 64bit).<br />
* Download the source code of the driver.<br />
* Compile and install the driver. <br />
<br />
$ ./configure --prefix=/usr<br />
$ make<br />
# make install<br />
<br />
If you have any problems on a 64 system, some other lib32 libraries may be required. Please adjust this page if that is the case.<br />
<br />
=== Adding missing paper sizes ===<br />
<br />
Some of the PPD files in {{AUR|epson-inkjet-printer-escpr2}} are missing paper size definitions for media that is supported by the printers and the filter. It is relatively straightforward to add the missing media types to the PPD files.<br />
<br />
To begin, download the PKGBUILD for the {{AUR|epson-inkjet-printer-escpr2}} package, either with an AUR helper or from a snapshot tarball. Once in the directory with the PKGBUILD, download and extract the source of the package by running {{ic|makepkg --nobuild}}.<br />
<br />
Change directory to to {{ic|src/epson-inkjet-printer-escpr2-$PKGVER}}. Open the file {{ic|src/optBase.h}} in a text editor for reference.<br />
<br />
Identify the PPD used by your printer in the {{ic|ppd}} directory. For example, a Workforce 7710 printer uses {{ic|Epson-WF-7710_Series-epson-escpr2-en.ppd}}. Let us call it {{ic|your_ppd_filename}}. Convert the relevant PPD to a PPD compiler source file using the {{ic|ppdi}} utility from the {{Pkg|cups}} package.<br />
<br />
$ ppdi -o your_ppd_filename.drv ppd/your_ppd_filename.ppd<br />
<br />
Open the newly-created {{ic|your_ppd_filename.drv}} in a text editor. Identify the section of the file with a lot of lines starting with {{ic|CustomMedia}}. Duplicate one such line to modify. For example:<br />
<br />
CustomMedia "Legal/US Legal" 612.00 1008.00 8.40 8.40 8.40 8.40 "<</PageSize[612.00 1008.00]/ImagingBBox null>>setpagedevice" "<</PageRegion[612.00 1008.00]/ImagingBBox null>>setpagedevice"<br />
<br />
The pair of numbers {{ic|612.00 1008.00}} represents the width and height of the paper in inches, multiplied by 72. Replace all three instances of these numbers with the dimensions of the paper you want to add. For example to add 11"x17" paper, replace the numbers with {{ic|792.00 1224.00}}.<br />
<br />
The string {{ic|"Legal/US Legal"}} identifies the paper. On the left side of the slash, {{ic|Legal}} is a magic identifier that the filter uses to identify the paper size. Replace it with the one you want to use. Refer to the {{ic|mediaSizeData}} array in {{ic|optBase.h}} for a list of possible values. The string to the right of the slash can be set to any human-readable value.<br />
<br />
If you want to enable borderless printing for a paper size, prefix the magic identifier string you just found with the letter T. So {{ic|Letter}} would become {{ic|TLetter}}. Additionally, change the four numbers {{ic|8.40 8.40 8.40 8.40}} to {{ic|0.00 0.00 0.00 0.00}}.<br />
<br />
For example, I was able to add 11x17 paper to the PPD for a Workforce 7710 by adding the following lines:<br />
<br />
CustomMedia "USB/US B(11x17 in)" 792.00 1224.00 8.40 8.40 8.40 8.40 "<</PageSize[792.00 1224.00]/ImagingBBox null>>setpagedevice" "<</PageRegion[792.00 1224.00]/ImagingBBox null>>setpagedevice"<br />
CustomMedia "TUSB/US B(11x17 in) (Borderless)" 792.00 1224.00 0.00 0.00 0.00 0.00 "<</PageSize[792.00 1224.00]/ImagingBBox null>>setpagedevice" "<</PageRegion[792.00 1224.00]/ImagingBBox null>>setpagedevice"<br />
<br />
Once you have added your custom size, recompile {{ic|your_ppd_filename.drv}} into a PPD file with ppdc (also from {{Pkg|cups}}):<br />
<br />
$ ppdc your_ppd_filename.drv<br />
<br />
This will create a ppd file in the {{ic|ppd}} directory with a file name derived from the {{ic|PCFileName}} parameter in {{ic|your_ppd_filename.drv}}. You can test this file by uploading it to the CUPS web interface, or install it permanently by overwriting the original PPD file and making the package with {{ic|makepkg}}.<br />
<br />
== HP ==<br />
<br />
See also [[CUPS/Troubleshooting#HP issues]].<br />
<br />
Most HP printers will use {{Pkg|hplip}}, some may use {{AUR|hpoj}}, while for multifunction laser printers {{aur|hpuld}} might be required. Some laser printers are also supported by {{AUR|foo2zjs-nightly}}.<br />
<br />
Notice that if {{ic|lpinfo -m}} tells you that the driver "requires proprietary plugin", you need to install {{AUR|hplip-plugin}}.<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| DeskJet 710C || rowspan="8" | {{AUR|pnm2ppa}} ||<br />
|-<br />
| DeskJet 712C ||<br />
|-<br />
| DeskJet 720C ||<br />
|-<br />
| DeskJet 722C ||<br />
|-<br />
| DeskJet 820se ||<br />
|-<br />
| DeskJet 820Cxi ||<br />
|-<br />
| DeskJet 1000Cse ||<br />
|-<br />
| DeskJet 1000Cxi ||<br />
|-<br />
| Envy 6452 series || {{Pkg|hplip}} || Search using mDNS/Bonjour<br />
|-<br />
| Envy 7800 series || {{Pkg|hplip}} || Have not tried [[foomatic]] yet<br />
|-<br />
| LaserJet P1606dn || rowspan="2" | {{Pkg|hplip}} + {{aur|hplip-plugin}} || Or {{aur|foo2zjs-nightly}}, or [[CUPS#CUPS|AirPrint]].<br />
|-<br />
| LaserJet Pro MFP M126nw ||<br />
|-<br />
| LaserJet Pro MFP M281fdw || rowspan="2" | {{Pkg|hplip}} || No proprietary drivers as of 2019-04-18 <br />
|-<br />
| Photosmart 2575 || Or use the hpijs driver in [[foomatic]].<br />
|-<br />
| HP LaserJet MFP M433 || rowspan="7" | {{aur|hpuld}} ||<br />
|-<br />
| HP LaserJet MFP M436 ||<br />
|-<br />
| HP LaserJet MFP M72625 72630 ||<br />
|-<br />
| Laser 10x Series ||<br />
|-<br />
| Laser MFP 13x Series ||<br />
|-<br />
| Color Laser 15x Series ||<br />
|-<br />
| Color Laser MFP 17x Series ||<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
=== HPLIP ===<br />
<br />
{{Note|As of hplip v3.17.11 hpijs is no longer available. If you have printers using hpijs they will fail to print. You must modify them and select the new hpcups driver instead.}}<br />
<br />
{{Pkg|hplip}} provides drivers for HP DeskJet, OfficeJet, Photosmart, Business Inkjet, and some LaserJet printers, and also provides an easy to use setup tool. See https://developers.hp.com/hp-linux-imaging-and-printing/supported_devices/index for the list of supported printers. hplip requires {{Pkg|python-pyqt5}} to run the GUI qt frontend. hp-setup requires [[CUPS]] to be installed and {{ic|cups.service}} to be started to save the printer.<br />
<br />
To run the setup tool with the GUI qt frontend:<br />
<br />
$ hp-setup -u<br />
<br />
To run the setup tool with the command line frontend:<br />
<br />
$ hp-setup -i<br />
<br />
To set up directly the configuration of a network connected HP printer:<br />
<br />
$ hp-setup -i ''ip_address''<br />
<br />
To run systray spool manager:<br />
<br />
$ hp-systray<br />
<br />
To generate a URI for a given ip address:<br />
<br />
# hp-makeuri ''<ip address>''<br />
<br />
PPD files are in {{ic|/usr/share/ppd/HP/}}.<br />
<br />
If your printer is [https://developers.hp.com/hp-linux-imaging-and-printing/binary_plugin.html listed as requiring a binary plugin], install the {{AUR|hplip-plugin}} package from [[AUR]].<br />
If the binary plugin {{AUR|hplip-plugin}} is a requirement you will need to [[start]] the {{ic|cups.service}} before the PPD is recognized by {{Pkg|hplip}}. If that does not work, reboot and log in with the printer ''off''. Then switch it on and run a test print.<br />
<br />
{{Note|Since at least with {{Pkg|hplip}} v3.22.10, `hp-setup` crashes when it detects '''hpfax://''' type of printer, with the message ''Unable to communicate with the device. Please check the device and try again''. This is likely due to the missing {{AUR|hplip-plugin}}, but can be bypassed by disabeling fax support on the printer itself.}}<br />
<br />
{{Note|{{Pkg|hplip}} depends on {{Pkg|foomatic-db-engine}} which prevents the drivers list from appearing when a printer is added to CUPS via the web user interface (following error : "Unable to get list of printer drivers"). Possible workarounds:<br />
* '''Either:''' Install {{Pkg|hplip}} first, then retrieve the PPD file that matches your printer from {{ic|/usr/share/ppd/HP/}}. Next, remove {{Pkg|hplip}} entirely as well as any unnecessary dependencies. Finally, install the printer manually using the CUPS web UI, selecting the PPD file you retrieved, and then re-install {{Pkg|hplip}}. After a reboot, you should have a fully working printer.<br />
* '''Or:''' Remove {{Pkg|hplip}}, {{Pkg|foomatic-db}} and {{Pkg|foomatic-db-engine}} along with any unnecessary dependencies. Reinstall {{Pkg|hplip}} and restart CUPS. Install your printer using the CUPS web UI, which should now be able to find the drivers automatically. No reboot needed.}}<br />
<br />
=== HPULD ===<br />
<br />
See [[Debian:CUPSPrintQueues#hpuld]] for more information.<br />
<br />
The package {{AUR|hpuld}} collects the sparse "HP + ULD" packages into one single package.<br />
<br />
=== foo2zjs ===<br />
<br />
[https://web.archive.org/web/20210129024712/http://foo2zjs.rkkda.com/ foo2zjs] supports some HP LaserJet printers. As of June 2018 the hplip package interferes with {{aur|foo2zjs-nightly}}, as described at [https://bbs.archlinux.org/viewtopic.php?pid=1662809 this forum post] and {{Bug|58815}}.<br />
<br />
== Kodak ==<br />
<br />
{{AUR|c2esp}} is free software. [https://sourceforge.net/projects/cupsdriverkodak/ Upstream notes] it is likely to work on all ESP and Hero printers/scanners.<br />
<br />
== Konica Minolta ==<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| Minolta Magicolor 1600W || rowspan=7 | [[foomatic]] ||<br />
|-<br />
| Minolta Magicolor 1680MF ||<br />
|-<br />
| Minolta Magicolor 1690MF ||<br />
|-<br />
| Minolta Magicolor 2480MF ||<br />
|-<br />
| Minolta Magicolor 2490MF ||<br />
|-<br />
| Minolta Magicolor 2530DL ||<br />
|-<br />
| Minolta Magicolor 4690MF ||<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
=== foo2zjs ===<br />
<br />
[[#foo2zjs]], mentioned above for supporting some HP printers, also support some Minolta printers.<br />
<br />
== Lexmark ==<br />
<br />
Note that most Lexmark printers are now supported by CUPS without needing further installation. See also [[SANE/Scanner-specific problems#Lexmark]] for Lexmark scanners issues.<br />
<br />
=== Utilities ===<br />
<br />
Lexmark provides a utility called ''lexijtools'' with the drivers.<br />
<br />
=== Custom drivers ===<br />
<br />
{{Out of date|This section was written before the i686 architecture stopped being supported. As such, it provides only an example with an i686 packages and needs to be updated by taking [[32-bit package guidelines]] into consideration.}}<br />
<br />
Lexmark does provide Linux drivers for all their hardware.<br />
The following packages are required:<br />
<br />
* {{Pkg|cups}}<br />
* {{Pkg|sane}}<br />
* {{Pkg|ncurses}}<br />
* {{Pkg|libusb}}<br />
* {{Pkg|libxext}}<br />
* {{Pkg|libxtst}}<br />
* {{Pkg|libxi}}<br />
* {{AUR|libstdc++5}}<br />
* {{Pkg|krb5}}<br />
* {{Pkg|lua}} (for the automated installer)<br />
* [[Java]] (for the automated installer, and some of the Lexmark tools)<br />
<br />
The drivers will need to be [http://support.lexmark.com/index?page=driversdownloads downloaded]{{Dead link|2022|09|17|status=404}} from Lexmark's website. Preferably, create a package (see [[Creating packages]]) and install it. Here is a basic [[PKGBUILD]] that still needs work but will give an idea of what is required.<br />
<br />
{{hc|PKGBUILD|<nowiki><br />
# Contributor: Todd Partridge (Gen2ly) toddrpartridge (at) yahoo<br />
<br />
pkgname=cups-lexmark-Z2300-2600<br />
pkgver=1<br />
pkgrel=1<br />
pkgdesc="Lexmark Z2300 and 2600 Series printer driver for cups"<br />
arch=('i686')<br />
url="http://www.lexmark.com/"<br />
license=('custom')<br />
depends=('cups' 'glibc' 'ncurses' 'libusb' 'libxext' 'libxtst' 'libxi' 'libstdc++5' 'krb5' 'lua' 'java-runtime')<br />
conflicts=('z600' 'cjlz35le-cups' 'cups-lexmark-700')<br />
source=(lexmark-inkjet-08-driver-1.0-1.i386.tar.gz.sh)<br />
md5sums=(3c37eb87e3dad4853bf29344f9695134)<br />
<br />
package() {<br />
# Extract installer<br />
sh lexmark-inkjet-08-driver-1.0-1.i386.tar.gz.sh --target Installer-Files<br />
cd Installer-Files<br />
mkdir Driver<br />
tar xvvf instarchive_all --lzma -C Driver/<br />
cd Driver<br />
tar xv lexmark-inkjet-08-driver-1.0-1.i386.tar.gz -C $pkgdir<br />
}<br />
</nowiki>}}<br />
<br />
Keep in mind you can use the automated installer but doing so will leave the resulting changes untracked. The PPD will be installed into {{ic|/usr/local/lexmark/lxk08/etc/}} or similar, depending on the printer model.<br />
<br />
== Oki ==<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| C110|| [[foomatic]] ||<br />
|-<br />
| MC561|| [[CUPS#Foomatic|foomatic-db-nonfree]] ||<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
== Ricoh ==<br />
<br />
Install {{AUR|openprinting-ppds-pxlmono-ricoh}} if your device is black and white, or {{AUR|openprinting-ppds-pxlcolor-ricoh}} if it is color. Note that Ricoh copiers are sometimes branded as Savin, Gestetner, Lanier, Rex-Rotary, Nashuatec, and/or IKON. So, if you have a device bearing one of these brands, it may be supported by these drivers as well.<br />
<br />
* [https://www.openprinting.org/driver/pxlmono-Ricoh List of supported black and white models]<br />
* [https://www.openprinting.org/driver/pxlcolor-Ricoh List of supported color models]<br />
<br />
For cheap [[Wikipedia:en:Graphics_Device_Interface#GDI printers|GDI-only winprinters]], which do not support PCL (Ricoh series SP100 and SP200) try out {{AUR|ricoh-sp100-git}}.<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| SP 112 || {{AUR|ricoh-sp100-git}} ||<br />
|-<br />
| SP 201n || {{AUR|ricoh-sp100-git}} ||<br />
|-<br />
| 213W || ''Generic PCL Laser'' || Obtain a WPS code by holding down the wifi button for 2 seconds, then hitting the stop/start button.<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
== Samsung ==<br />
<br />
Since 2016, or 2017, Samsung is no longer in the printers/scanners business. As of 2019, HP partially support some of Samsung printers/scanners. Before 2016, Samsung was a major player. Which is why there are still many Samsung machines around. In addition, Linux, and cups, keep evolving. The bottom line of all this is that supporting Samsung products is at a flux.<br />
<br />
A major site for information about Samsung printers/scanners is [https://www.bchemnet.com/suldr/ Samsung Unified Linux Driver Repository]. Despite its name, it is not affiliated by Samsung. Neither it is devoted only to {{AUR|samsung-unified-driver}}. {{ic|samsung-unified-driver}}, on the other hand, is close source by Samsung. It also encompass Windows and Mac. It might be the first stop to get a driver for a Samsung printer and scanner as it, or was, claim to support practically every one of these. Note that {{ic|samsung-unified-driver}} includes software that can stand on its own, not tied to cups. If you can not get the printer to work with cups, you might try this route.<br />
<br />
That said, there are more options. An overview is at [https://www.bchemnet.com/suldr/alternatives.html alternatives].<br />
<br />
* Out of CJX-XXX series, at least CJX-1000, CJX-1050W, and CJX-2000FW are reported to work with {{AUR|c2esp}}, even though {{ic|c2esp}} is supposedly for Kodak products. <br />
* For [https://ghostarchive.org/archive/vj6tA Samsung Printer Language], there is {{Pkg|splix}}. For a list of models that are supported, see its [http://splix.ap2c.org/ home page]. Other SPL Samsung printers, even tough not in that list, might work with {{ic|splix}}. <br />
* QPDL (Quick Page Description Language) printers, some of which are supported by {{ic|splix}}, are also supported by by {{ic|foo2qpdl}}, provided by the [[#foo2zjs]] package. A list of known to work models is [https://web.archive.org/web/20210312142508/http://www.foo2qpdl.rkkda.com/ here].<br />
All of {{ic|c2esp}}, {{ic|splix}} and {{ic|foo2zjs}} are free software.<br />
<br />
You should also note that many Samsung printers support PostScript. Chances are that it will work with CUPS generic postscript printer, especially if it is only black & white and only printer, without a scanner added to it. Generic driver may be missing functionality or limited, for example in their support for duplex, color control, and resolution settings, and print quality may be lower.<br />
<br />
== Xerox or FujiXerox ==<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| DocuPrint 203A || {{Pkg|hplip}} || Using the '''DocuPrint P8e(hpijs)''' driver, or the Brother driver on FujiXerox's website (see [[#Brother]] for more information on how to install custom Brother drivers).<br />
|-<br />
| Phaser 3100MFP || Install Xerox's driver || See [[#Phaser 3100MFP]] for more instructions.<br />
|-<br />
| Phaser 6115MFP || [[foomatic]] ||<br />
|-<br />
| Phaser 6121MFP || [[foomatic]] ||<br />
|-<br />
| Xerox Workcentre 3119 || {{Pkg|splix}} || Since Samsung SCX-4200 is the rebranded Xerox 3119, splix package works for both<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
=== Custom drivers ===<br />
<br />
==== Phaser 3100MFP ====<br />
<br />
{{Warning|This section involves installing packages without [[pacman]]. These directions should ideally be automated with a [[PKGBUILD]].}}<br />
<br />
Once you have downloaded the drivers, execute the driver installer and accept the licence:<br />
<br />
# cd printer<br />
# ./XeroxPhaser3100.install<br />
<br />
Note that the driver is 32 bit, so some 32 bit libraries will be required on an x86_64 system: {{pkg|lib32-libpng12}}, {{pkg|lib32-zlib}}, {{pkg|lib32-libjpeg6-turbo}}, {{pkg|lib32-libcups}}, {{pkg|lib32-libxext}}, {{pkg|lib32-libx11}}, {{pkg|lib32-gcc-libs}}, {{aur|lib32-libstdc++5}}<br />
<br />
For the scanner, create an {{ic|/etc/sane.d}} directory if it does not already exist, because it is needed by the installer:<br />
<br />
# mkdir -p /etc/sane.d<br />
<br />
Now install the driver:<br />
<br />
# cd scanner/<br />
# ./XeroxPhaser3100sc.install<br />
<br />
Again, on an x86_64 install, 32 bit libraries will be needed.<br />
<br />
==== Phaser 6000B ====<br />
<br />
[[Install]] the [https://github.com/aur-archive/xerox-phaser-6010 xerox-phaser-6010] package (archived from the AUR).<br />
The driver may require older versions of {{Pkg|nettle}} and {{Pkg|gnutls}} to be installed, since the binary blob linked against older versions of the shared libraries provided by those packages. The oldest known-good versions are {{ic|nettle-2.7.1-1}} and {{ic|gnutls-3.3.13-1}}.<br />
<br />
==== Phaser 6125N ====<br />
<br />
{{Warning|This section involves installing packages without [[pacman]]. These directions should ideally be automated with a [[PKGBUILD]].}}<br />
<br />
FujiXerox does not support Linux on this model. An old rpm [https://onlinesupport.fujixerox.com/tiles/common/hc_drivers_download.jsp?system=%27Linux%27&shortdesc=null&xcrealpath=http://www.fujixeroxprinters.com/downloads/uploaded/dpc525a_linux_.0.0.tar_81c2.zip is available]{{Dead link|2022|09|17|status=SSL error}} but does not seem to work.<br />
<br />
A slightly adapted [https://rickvanderzwet.nl/trac/personal/wiki/XeroxPhaser6125N custom driver] has been found to work out of the box.<br />
<br />
To install the tarball, run:<br />
<br />
# tar -C / --keep-newer-files -xvzf cups-xerox-phaser-6125n-1.0.0.tar.gz</div>Oliverhttps://wiki.archlinux.org/index.php?title=CUPS/Printer-specific_problems&diff=771513CUPS/Printer-specific problems2023-03-07T15:13:16Z<p>Oliver: /* HPLIP */ fax support causes crashes in hp-setup, upstream bugreport pending</p>
<hr />
<div>[[Category:Printers]]<br />
[[ja:CUPS/プリンター別の問題]]<br />
[[ru:CUPS (Русский)/Printer-specific problems]]<br />
{{Related articles start}}<br />
{{Related|CUPS}}<br />
{{Related|CUPS/Troubleshooting}}<br />
{{Related articles end}}<br />
<br />
This article contains printer or manufacturer-specific instructions for [[CUPS]].<br />
See [https://www.openprinting.org/printers OpenPrinting] if your printer is not already listed here, or if none of the listed drivers work.<br />
<br />
{{Note|If you add a printer to this list, consider contributing your entry to [https://wiki.linuxfoundation.org/openprinting/database/databaseintro OpenPrinting] - that way users of other distributions will also benefit!}}<br />
<br />
== Brother ==<br />
<br />
{{Note|Some printer models can be found in several entries because there are several packages or drivers for them.}}<br />
<br />
Drivers for several models:<br />
<br />
{|class="wikitable"<br />
! Printers<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| DCP-1510 series (DCP-1510, DCP-1510r, DCP-1511, DCP-1512, DCP-1512r, DCP-1518) || {{AUR|brother-dcp1510}} ||<br />
|-<br />
| DCP-7010, DCP-7020, DCP-7025, DCP-8060, DCP-8065DN, FAX-2820, FAX-2920, HL-2030, HL-2040, HL-2070N, HL-5240, HL-5250DN, HL-5270DN, HL-5280DW, MFC-7220, MFC-7225N, MFC-7420, MFC-7820N, MFC-8460N, MFC-8660DN, MFC-8860DN, MFC-8870DW || {{AUR|brother-cups-wrapper-laser}} ||<br />
|-<br />
| HL-4040CN, HL-4040CDN, HL-4050CDN, HL-4070CDW, MFC-9440CN, MFC-9450CDN, MFC-9840CDW, DCP-9040CN, DCP-9042CDN, DCP-9045CDN || {{AUR|brother-cups-wrapper-ac}} ||<br />
|-<br />
| DCP-1510 series, DCP-1600 series, DCP-7030, DCP-7040, DCP-7055, DCP-7055W, DCP-7060D, DCP-7065DN, DCP-7080, DCP-L2500D series, DCP-L2520D series, DCP-L2540DW series, HL-1110 series, HL-1200 series, HL-2030 series, HL-2140 series, HL-2220 series, HL-2270DW series, HL-5030 series, HL-L2300D series, HL-L2320D series, HL-L2340D series, HL-L2360D series, MFC-1910W, MFC-1919NW, MFC-7240, MFC-7360N, MFC-7365DN, MFC-7840W, Lenovo M7605D || {{AUR|brlaser}}<br />{{AUR|brlaser-git}} || Unofficial driver, may be compatible with more models<br />
|}<br />
<br />
Drivers for one model:<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| DCP-135C || {{AUR|brother-dcp135c}} ||<br />
|-<br />
| DCP-150C || {{AUR|brother-dcp150c}} ||<br />
|-<br />
| DCP-150C || {{AUR|brother-dcp150c}} ||<br />
|-<br />
| DCP-2550DW ||{{AUR|brother-dcp-l2550dw}} ||<br />
|-<br />
| DCP-B7500D || {{AUR|brother-dcpb7500d}} ||<br />
|-<br />
| DCP-L3550CDW || {{AUR|brother-dcpl3550cdw}} || Use IPP driver as described [https://aur.archlinux.org/packages/brother-dcpl3550cdw/#comment-728480 here] and [https://www.printerforums.net/threads/brother-dcp-l3550cdw.68978/ here].<br />
|-<br />
| DCP-7020 || [[foomatic]] || Or Brother's driver.<br />
|-<br />
| DCP-7030 || {{AUR|brother-dcp7030}} ||<br />
|-<br />
| DCP-7065DN || {{AUR|brother-dcp7065dn}} ||<br />
|-<br />
| DCP-9020CDW || {{AUR|brother-dcp-9020cdw}} ||<br />
|-<br />
| DCP-J515W || {{AUR|brother-dcp-j515w}} ||<br />
|-<br />
| DCP-J4110DW || {{AUR|brother-dcpj4110dw}} ||<br />
|-<br />
| DCP-J1200W || {{AUR|brother-dcpj1200w}} || "DCPJ1200W" is added automatically to cups when installing this aur package. multilib not required. SANE drivers for this model: {{AUR|brscan5}}<br />
|-<br />
| FAX-2820 || {{AUR|brother-cups-wrapper-laser}} ||<br />
|-<br />
| FAX-2840 || {{AUR|brother-fax2840}} || Or [[foomatic]] - works mostly with {{ic|hpijs-pcl5e.ppd}}. Same as the HL-2170W.<br />
|-<br />
| FAX-2940 || {{AUR|brother-fax2940}} ||<br />
|-<br />
| HL-1110 || {{AUR|brlaser-git}} || Tested and it works<br />
|-<br />
| HL-2030 || [[foomatic]] || Or {{AUR|brother-hl2030}}<br />
|-<br />
| HL-2035 || [[foomatic]] || Should be compatible with any drivers for the HL-2030.<br />
|-<br />
| HL-2040 || [[foomatic]] || Or {{AUR|brother-hl2040}}<br />
|-<br />
| HL-2130 || [[foomatic]] (using the HL-2140 driver) || Or {{Pkg|hplip}}<br />
|-<br />
| HL-2135W || {{AUR|brother-brgenml1}} ||<br />
|-<br />
| HL-2140 || [[foomatic]] || Or {{AUR|brother-hl2140}}<br />
|-<br />
| HL-2170W || [[foomatic]] || Or Brother's driver. <br />
|-<br />
| HL-2230 || [[foomatic]] || Same as HL-2170W. Select HL-2170W as the driver in CUPS admin when adding a printer.<br />
|-<br />
| HL-2250DN || {{AUR|brother-brgenml1}} || {{AUR|brother-hl2250dn}} is broken?<br />
|-<br />
| HL-2270DW || {{AUR|brother-hl2270dw}} ||<br />
|-<br />
| HL-2280DW || {{AUR|brother-hl2280dw}} ||<br />
|-<br />
| HL-3045CN || Install Brother's driver or {{AUR|brother-hl3040cn}}.||<br />
|-<br />
| HL-3140CW || {{AUR|brother-hl3140cw}} || Use IPP and Brother's driver to avoid page-shrinking and endless blank printouts<br />
|-<br />
| HL-3150CDW || {{AUR|brother-hl3150cdw}} ||<br />
|-<br />
| HL-3170CDW || {{AUR|brother-hl3170cdw}} ||<br />
|-<br />
| HL-4150CDN || {{AUR|brother-hl4150cdn}} ||<br />
|-<br />
| HL-5140 || [[foomatic]] || Or Brother's driver.<br />
|-<br />
| HL-5340 || [[foomatic]] || Using the ''Generic PCL 6/PCL XL Printer - CUPS+Gutenprint'' ({{Pkg|gutenprint}} and {{Pkg|foomatic-db-gutenprint-ppds}}). Or Brother's driver, which may result in failed prints with postscript errors.<br />
|-<br />
| HL-L2300D || {{AUR|brother-hll2300d}} || {{AUR|brlaser-git}} works better. Using the brother driver, only defaults are honored and print-specific settings are ignored.<br />
|-<br />
| HL-L2340DW || {{AUR|brother-hll2340dw}} ||<br />
|-<br />
| HL-L2350DW || {{AUR|brother-hll2350dw}} ||<br />
|-<br />
| HL-L2360DN || {{AUR|brother-hll2360d}} || Or {{AUR|brlaser-git}}<br />
|-<br />
| HL-L2360DW || {{AUR|brother-hll2360d}} || {{AUR|brlaser-git}} should works.<br />
|-<br />
| HL-L2365DW || {{AUR|brother-hll2360d}} || {{AUR|brlaser-git}} should works.<br />
|-<br />
| HL-L2380DW || {{AUR|brother-hll2380dw}} ||<br />
|-<br />
| HL-L2395DW || {{AUR|brother-hll2395dw}} || Use the {{ic|socket}} protocol as described in [[#Network printers]]<br />
|-<br />
| HL-L3230CDW || {{AUR|brother-hll3230cdw}} || Or https://github.com/splitbrain/archlinux-brother-hll3230cdw<br />
|-<br />
| HL-L3270CDW || {{AUR|brother-hll3270cdw}} || Use the {{ic|lpd}} protocol as described in [[#Network printers]].<br />
|-<br />
| HL-L5100DN || HP LaserJet Foomatic driver || This model will emulate a HP LaserJet. Use the {{ic|lpd}} protocol as described in [[#Network printers]].<br />
|-<br />
| HL-L8360CDW || {{AUR|brother-hll8360cdw-cups-bin}} ||<br />
|-<br />
| MFC-420CN || {{AUR|brother-mfc-420cn}} ||<br />
|-<br />
| MFC-440CN || {{AUR|brother-mfc-440cn}} ||<br />
|-<br />
| MFC-7360N || {{AUR|brother-mfc7360n}} || Or {{AUR|brlaser-git}}<br />
|-<br />
| MFC-7460DN || [[Gutenprint]] || Use the ''Generic PCL 6 Printer wide margin - CUPS+Gutenprint'' driver, with address {{ic|ipp://hostname-or-ip/pcl_p1}}.<br />
|-<br />
| MFC-7840W || {{AUR|brother-mfc-7840w}} || Or {{AUR|brlaser-git}}<br />
|-<br />
| MFC-9320CW || Install Brother's driver. ||<br />
|-<br />
| MFC-9332CDW || {{AUR|brother-mfc-9332cdw}} ||<br />
|-<br />
| MFC-9840CDW || [[foomatic]] || Or Brother's driver. This printer also works with the generic PCL-6 driver from the {{Pkg|gutenprint}} package. Use '''pcl_p1''' for the printer's address when using the PCL-6 driver.<br />
|-<br />
| MFC-J1300DW || {{AUR|brother-mfc-j1300dw}} || Use the {{ic|ipp}} protocol as described in [[#Network printers]].<br />
|-<br />
| MFC-J435W || {{AUR|brother-mfc-j435w}} || Use {{ic|lpd://[printer_addr]/BINARY_P1}} or {{ic|http://[printer_addr]/POSTSCRIPT_P1}} as described in the comments section of the AUR package page.<br />
|-<br />
| MFC-J470DW || {{AUR|brother-mfc-j470dw}} || Use the {{ic|ipp}} protocol as described in [[#Network printers]].<br />
|-<br />
| MFC-J4710DW || {{AUR|brother-mfc-j4710dw}} ||<br />
|-<br />
| MFC-J480DW || {{AUR|brother-mfc-j480dw}} || Use the {{ic|ipp}} protocol as described in [[#Network printers]].<br />
|-<br />
| MFC-J5520DW || {{AUR|brother-mfc-j5520dw}} ||<br />
|-<br />
| MFC-J5845DW || {{AUR|brother-mfc-j5845dw}} || Use the {{ic|ipp}} protocol as described in [[#Network printers]].<br />
|-<br />
| MFC-J5910DW || {{AUR|brother-mfc-j5910dw}} ||<br />
|-<br />
| MFC-J650DW || Install Brother's driver. ||<br />
|-<br />
| MFC-J885DW || {{AUR|brother-mfc-j885dw}} ||<br />
|-<br />
| MFC-J985DW || {{AUR|brother-mfc-j985dw}} ||<br />
|-<br />
| MFC-L2700DN || {{AUR|brother-mfc-l2700dn}} || Please look also at the comments section of the AUR package page. <br />
|-<br />
| MFC-L2700DW || {{AUR|brother-mfc-l2700dw}} || Please look also at the comments section of the AUR package page. <br />
|-<br />
| MFC-L2710DN || {{AUR|brother-mfc-l2700dn}} || Use the {{ic|ipp}} protocol as described in [[#Network printers]].<br />
|-<br />
| MFC-L2710DW || {{AUR|brother-mfc-l2710dw}} || Use the {{ic|lpd}} protocol as described in [[#Network printers]].<br />
|-<br />
| MFC-L2720DW || {{AUR|brother-mfc-l2720dw}} || Please look also at the comments section of the AUR package page. <br />
|-<br />
| MFC-L2730DW || {{AUR|brother-mfc-l2730dw}} || Please look also at the comments section of the AUR package page. <br />
|-<br />
| MFC-L2740DW || {{AUR|brother-mfc-l2740dw}} || Please look also at the comments section of the AUR package page. <br />
|-<br />
| MFC-L5800DW || {{AUR|brother-mfc-l5750dw}} || <br />
|-<br />
| MFC-L8600CDW || {{AUR|brother-mfc-l8600cdw}} || Please follow the instructions on the AUR page.<br />
|-<br />
| QL-500 || {{AUR|brother-ql500}} ||<br />
|-<br />
| QL-570 || {{AUR|brother-ql570}} ||<br />
|-<br />
| QL-580N || {{AUR|brother-ql580n}} ||<br />
|-<br />
| QL-650TD || {{AUR|brother-ql650td}} ||<br />
|-<br />
| QL-700 || {{AUR|brother-ql700}} ||<br />
|-<br />
| QL-710W || {{AUR|brother-ql710w}} ||<br />
|-<br />
| QL-720NW || {{AUR|brother-ql720nw}} ||<br />
|-<br />
| QL-1050 || {{AUR|brother-ql1050}} || <br />
|-<br />
| QL-1050N || {{AUR|brother-ql1050n}} ||<br />
|-<br />
| QL-1060 || {{AUR|brother-ql1060n}} ||<br />
|-<br />
| QL-1110NWB || {{AUR|brother-ql1110nwb}} ||<br />
|-<br />
| TD-2020 || {{AUR|brother-td2020}} ||<br />
|-<br />
| TD-2120N || {{AUR|brother-td2120n}} ||<br />
|-<br />
| TD-2130N || {{AUR|brother-td2130n}} ||<br />
|-<br />
| TD-4000 || {{AUR|brother-td4000}} ||<br />
|-<br />
| TD-4100N || {{AUR|brother-td4100n}} ||<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
=== Network printers ===<br />
<br />
For network printers, use {{ic|ipp://'''printer_ip'''/ipp/port1}} as printer address.<br />
For some older printers, this might not work. If not, try {{ic|lpd://'''printer_ip'''/BINARY_P1}} instead.<br />
<br />
Some printers use the socket protocol. For these printers, use {{ic|socket://'''printer_ip''':9100}}.<br />
For http, use {{ic|http://'''printer_ip'''/POSTSCRIPT_P1}}.<br />
<br />
=== Custom drivers ===<br />
<br />
Brother provides custom drivers on their website, either in source tarball, rpm, or deb form. [[Packaging Brother printer drivers]] covers creating [[PKGBUILD]]s from the existing RPM packages.<br />
<br />
{{Note|The source packages might be a better alternative to the rpm packages, provided they contain all the needed files.}}<br />
<br />
==== Manually installing from the RPM packages ====<br />
<br />
{{Warning|This should ideally be automated in a [[PKGBUILD]].}}<br />
<br />
[[Install]] the {{Pkg|rpmextract}} package, and extract both rpm packages using {{ic|rpmextract.sh}}. Extracting both files will create a var and a usr directory - move the contents of both directories into the corresponding root directories.<br />
<br />
Run the cups wrapper file in {{ic|/usr/local/Brother/cupswrapper}}. This should automatically install and configure your brother printer.<br />
<br />
For some of the drivers 32 bit libraries may need to be installed from [[multilib]].<br />
<br />
=== Updating the firmware ===<br />
<br />
[[Install]] {{Pkg|net-snmp}} and run:<br />
<br />
$ snmpwalk -c public $PRINTER_IP | grep -A 1 3.6.1.4.1.2435.2.4.3.99.3.1.6.1.2<br />
<br />
Or alternatively:<br />
<br />
$ snmpwalk -v 2c -c public 192.168.23.11 iso.3.6.1.4.1.2435.2.4.3.99.3.1.6.1.2<br />
<br />
At this point, you will have the relevant data to get a valid firmware download link from Brother. The file should look similar to the one below:<br />
<br />
{{hc|request.xml|<br />
<REQUESTINFO><br />
<FIRMUPDATETOOLINFO><br />
<FIRMCATEGORY>MAIN</FIRMCATEGORY><br />
<OS>LINUX</OS><br />
<INSPECTMODE>1</INSPECTMODE><br />
</FIRMUPDATETOOLINFO><br />
<br />
<FIRMUPDATEINFO><br />
<MODELINFO><br />
<SELIALNO></SELIALNO><br />
<NAME>MFC-9330CDW</NAME><br />
<SPEC>0401</SPEC><br />
<DRIVER></DRIVER><br />
<FIRMINFO><br />
<FIRM><br />
<ID>MAIN</ID><br />
<VERSION>R1506121801:4504</VERSION><br />
</FIRM><br />
<FIRM><br />
<ID>SUB1</ID><br />
<VERSION>1.07</VERSION><br />
</FIRM><br />
<FIRM><br />
<ID>SUB2</ID><br />
<VERSION>L1505291600</VERSION><br />
</FIRM><br />
</FIRMINFO><br />
</MODELINFO><br />
<DRIVERCNT>1</DRIVERCNT><br />
<LOGNO>2</LOGNO><br />
<ERRBIT></ERRBIT><br />
<NEEDRESPONSE>1</NEEDRESPONSE><br />
</FIRMUPDATEINFO><br />
</REQUESTINFO><br />
}}<br />
<br />
Post this file to Brother:<br />
<br />
$ curl -X POST -d @request.xml https://firmverup.brother.co.jp/kne_bh7_update_nt_ssl/ifax2.asmx/fileUpdate -H "Content-Type:text/xml" > response.xml<br />
<br />
In {{ic|response.xml}} you will find a {{ic|<PATH>}} tag that contains the firmware download URL. Next, download the firmware, push it to the printer, and let the printer process it. Before that is done, change the Admin password to something known, it will be used as the user to log into the FTP site (VERY bad practice, do not do this). <br />
<br />
$ wget http://update-akamai.brother.co.jp/CS/LZ4266_W.djf<br />
$ ftp $PRINTER_IP|<br />
ftp> bin<br />
ftp> hash<br />
ftp> send LZ4266_W.djf<br />
ftp> bye<br />
<br />
With that, the printer will restart, and the latest firmware will be installed and (hopefully) your printing woes will be solved.<br />
<br />
=== IPP-over-USB ===<br />
<br />
You might experience some trouble while using the USB port on certain models. <br />
<br />
Brother provides a shell script to create udev rules to prevent the use of IPP-over-USB. This might solve USB printing problems but means that you need to use the legacy LPR driver. See the [https://support.brother.com/g/b/faqend.aspx?c=us_ot&lang=en&prod=mfcl9570cdw_us_eu_as&faqid=faq00100729_000 FAQ article].<br />
<br />
== Canon ==<br />
<br />
There are many possible drivers for Canon printers. [https://gimp-print.sourceforge.net/p_Supported_Printers.php Many Canon printers] are supported by [[Gutenprint]] and {{pkg|foomatic-db-ppds}}. Some of Canon's LBP, iR, and MF printers use a driver supporting the UFR II/UFR II LT/LIPSLX protocols, [[#UFRII]] . Others use the [[#CARPS]], or [[#cnijfilter]] ({{AUR|cnijfilter2}} / {{AUR|cnijfilter2-bin}}), or [[Canon CAPT]] drivers.<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| iP4300 || rowspan="2" | [[Gutenprint]] || Or use the [https://www.turboprint.info/ TurboPrint] driver.<br />
|-<br />
| PIXMA G4000 series|| Misidentifies itself as Canon G3010 Series. Use Canon PIXMA G4000 - CUPS+Gutenprint driver instead.<br />
|-<br />
| LBP810 || rowspan="34" | [[Canon CAPT]] ||<br />
|-<br />
| LBP1120 ||<br />
|-<br />
| LBP1210 ||<br />
|-<br />
| LBP2900 ||<br />
|-<br />
| LBP3000 ||<br />
|-<br />
| LBP3010 ||<br />
|-<br />
| LBP3018 ||<br />
|-<br />
| LBP3050 ||<br />
|-<br />
| LBP3100 ||<br />
|-<br />
| LBP3108 ||<br />
|-<br />
| LBP3150 ||<br />
|-<br />
| LBP3200 ||<br />
|-<br />
| LBP3210 ||<br />
|-<br />
| LBP3250 ||<br />
|-<br />
| LBP3300 ||<br />
|-<br />
| LBP3310 ||<br />
|-<br />
| LBP3500 ||<br />
|-<br />
| LBP5000 ||<br />
|-<br />
| LBP5050 series ||<br />
|-<br />
| LBP5100 ||<br />
|-<br />
| LBP5300 ||<br />
|-<br />
| LBP6000 ||<br />
|-<br />
| LBP6018 ||<br />
|-<br />
| LBP6020 ||<br />
|-<br />
| LBP6200 ||<br />
|-<br />
| LBP6300 ||<br />
|-<br />
| LBP6300n ||<br />
|-<br />
| LBP6310dn ||<br />
|-<br />
| LBP7010C ||<br />
|-<br />
| LBP7018C ||<br />
|-<br />
| LBP7200Cdn (network mode) ||<br />
|-<br />
| LBP7200C series ||<br />
|-<br />
| LBP7210Cdn ||<br />
|-<br />
| LBP9100C ||<br />
|-<br />
| MF216n (network over ldp) || rowspan="4" | {{AUR|cndrvcups-lb-bin}} ||<br />
|-<br />
| MF635Cx ||<br />
|-<br />
| MF4720w ||<br />
|-<br />
| MF4770n ||<br />
|-<br />
| MG4200 series || {{AUR|cnijfilter-mg4200}} || Avoid the [[CUPS#Web interface|web interface]] when adding the printer as it will not find the PPD file.<br />
|-<br />
| MB2350 || rowspan="6" | {{AUR|cnijfilter2}}<br />{{AUR|cnijfilter2-bin}} ||<br />
|-<br />
| MX490 ||<br />
|-<br />
| MX492 ||<br />
|-<br />
| TR8500 series ||<br />
|-<br />
| TS202 ||<br />
|-<br />
| TS3100 series ||<br />
|-<br />
| TS8050 || Without {{AUR|cnijfilter2}} printing will fail with a filter error or you might get "Rendering Completed" and nothing will print<br />
|-<br />
| TS9020 || {{AUR|canon-ts9020}} ||<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
Some Canon printers will use a similar setup to the iP4500, so consider modifying the {{AUR|cnijfilter-ip4500}} package for other, similar printers.<br />
<br />
=== UFRII ===<br />
<br />
Many LBP, iR, and MF printers use a protocol that has had several names over the years: UFR II, UFR II LT, LIPSLX. There are multiple packages for these printers in AUR, and at least the imageCLASS MF4570dn and i-sensys MF633C are reported to only work with the older v3.70 version.<br />
<br />
{{AUR|cnrdrvcups-lb}} v 5.00: latest version built from source<br />
<br />
{{AUR|cndrvcups-lb}} 3.70 and {{AUR|cndrvcups-common-lb}} 4.10: older version built from source<br />
<br />
{{AUR|cndrvcups-lb-bin}} v3.70: uses Canon provided binaries with location/config adjustments to make them work on Arch Linux<br />
<br />
=== CARPS ===<br />
<br />
Some of Canon's printers use Canon's proprietary CARPS (''Canon Advanced Raster Printing System'') driver.<br />
[https://www.rainbow-software.org/2014/01/23/cups-driver-for-canon-carps-printers/ Rainbow Software] have managed to reverse engineer the CARPS data format and have successfully created a CARPS CUPS driver, which is available as {{AUR|carps-cups-git}}.<br />
The project's [https://github.com/ondrej-zary/carps-cups GitHub] page includes a list of working printers.<br />
<br />
=== USB over IP (BJNP) ===<br />
<br />
Some Canon printers use Canon's proprietary USB over IP BJNP protocol to communicate over the network. There is a CUPS backend for this, which is available as {{AUR|cups-bjnp}}.<br />
<br />
=== cnijfilter ===<br />
<br />
Some printers using the cnijfilter drivers support the {{ic|cnijnet}} protocol. To find the [[CUPS#Printer URI|printer URI]] run<br />
<br />
$ cnijnetprn --search auto<br />
<br />
and use the {{ic|cnijnet:/}} URI in the output.<br />
<br />
Other driver versions, as is the case for the current version of {{AUR|cnijfilter2}}, provide the {{ic|cnijlgmon3}} binary to search for available printers.<br />
<br />
{{hc|$ cnijlgmon3|output=<br />
network cnijbe2://Canon/?port=net&serial=60-12-81-A7-7D-34 "Canon MB2300 series" "Canon-MB2300-series_60-12-81-A7-7D-34"<br />
}}<br />
<br />
The printer can be added to cups using the {{ic|cnijbe2}} url and an appropriate {{ic|.ppd}} file, which should be shipped with your driver. <br />
<br />
$ lpadmin -p CustomPrinterNameMB2300 -P /usr/share/cups/model/canonmb2300.ppd -v "cnijbe2://Canon/?port=net&serial=60-12-81-A7-7D-34" -E<br />
<br />
The argument {{ic|serial}} in the cnijbe2 url corresponds to the MAC address of the printer.<br />
<br />
=== IPP Everywhere ===<br />
<br />
For recent Canon printers, like the G7000 series, it can be hard to find a valid driver. However, it is possible to use a driverless installation using IPP Everywhere.<br />
<br />
If you have installed avahi, CUPS should be able to detect your printer automatically.<br />
<br />
However, if it fails, you can always enter your printer settings manually. In CUPS web interface select {{ic|Internet Printing Protocol (ipp)}} and enter the IPP URL of the printer. Then at the driver selection screen select{{ic|Generic > {current_make_and_model} - IPP Everywhere ™}}.<br />
<br />
For the G7000 series the IPP URL is {{ic|ipp://<printer_ip>}} or {{ic|ipps://<printer_ip>}}.<br />
<br />
== Dell ==<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| 1250C<br />
| rowspan=2 | {{AUR|foo2zjs-nightly}}<br />
| rowspan=2 | The printer may also work with the [[#Phaser 6000B|Xerox Phaser 6000B driver]].<br />
|-<br />
| C1660NW<br />
|-<br />
| E515<br />
| rowspan=2 | Install [https://downloads.dell.com/FOLDER03040853M/1/Printer_E515dw_Driver_Dell_A00_LINUX.zip Dell's driver].<br />
| rowspan=2 | Both ''e515dwcupswrapper-3.2.0-1.i386.deb'' and ''e515dwlpr-3.2.0-1.i386.deb'' need to be installed. You could either write a [[PKGBUILD]], use {{AUR|debtap}}, or use {{Pkg|dpkg}} (using dpkg is not recommended as the files will not be managed by [[pacman]]). The driver works on both the x86_64 and i386 platforms, but may require [[multilib]].<br />
|-<br />
| E515dw<br />
|-<br />
| S1130n || rowspan="16" | {{aur|dell-unified-driver}} || rowspan="16" | Driver conflicts with samsung-unified-driver-printer (as the dell-unified-driver appears to be based on the Samsung one, and they create several of the same files)<br />
|-<br />
|1130<br />
|-<br />
|1133<br />
|-<br />
|1135n<br />
|-<br />
|1815<br />
|-<br />
|2145cn<br />
|-<br />
|2335dn<br />
|-<br />
|2355dn<br />
|-<br />
|5330<br />
|-<br />
|B1160<br />
|-<br />
|B1160w<br />
|-<br />
|B1165nfw<br />
|-<br />
|B1260dn<br />
|-<br />
|B1265dfw<br />
|-<br />
|B1265dnf<br />
|-<br />
|B2365dnf<br />
|-<br />
<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
== Epson ==<br />
<br />
{{AUR|epson-inkjet-printer-escpr}} and {{AUR|epson-inkjet-printer-escpr2}} are sets of drivers using the Epson Inkjet Printer Driver (ESC/P-R) for Linux.<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| AcuLaser C900 || || This printer uses Epson's driver, with a device URI of ''''usb://EPSON/AL-C900'''', and may need the pipsplus service to be running.<br />
|-<br />
| EP-50V || rowspan="4" | {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| EP-879A ||<br />
|-<br />
| EP-880A ||<br />
|-<br />
| EP-881A ||<br />
|-<br />
| ET-2700 || rowspan="2" | {{AUR|epson-inkjet-printer-escpr}} ||<br />
|-<br />
| ET-2750 ||<br />
|-<br />
| ET-3700 || rowspan="5" | {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| ET-3750 ||<br />
|-<br />
| ET-3760 ||<br />
|-<br />
| ET-4750 ||<br />
|-<br />
| ET-4760 ||<br />
|-<br />
| EW-M571T || {{AUR|epson-inkjet-printer-escpr}} ||<br />
|-<br />
| EW-M670FT || {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| L380 || rowspan="2" | {{AUR|epson-inkjet-printer-201601w}} ||<br />
|-<br />
| L382 ||<br />
|-<br />
| L3150 || rowspan="3" | {{AUR|epson-inkjet-printer-escpr}} ||<br />
|-<br />
| L4150 ||<br />
|-<br />
| L4160 ||<br />
|-<br />
| L6160 || rowspan="3" | {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| L6170 ||<br />
|-<br />
| L6190 ||<br />
|-<br />
| LP-S5000 || || This printer requires a [[#Avasys|custom driver from Avasys]].<br />
|-<br />
| PM-520 || rowspan="11" | {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| PX-M5080F ||<br />
|-<br />
| PX-M5081F ||<br />
|-<br />
| PX-M680F ||<br />
|-<br />
| PX-M7070FX ||<br />
|-<br />
| PX-M780F ||<br />
|-<br />
| PX-M781F ||<br />
|-<br />
| PX-M884F ||<br />
|-<br />
| PX-S5080 ||<br />
|-<br />
| PX-S7070X ||<br />
|-<br />
| PX-S884 ||<br />
|-<br />
| TX125 || {{AUR|epson-inkjet-printer-n10-nx127}} ||<br />
|-<br />
| WF-3620 || {{AUR|epson-inkjet-printer-escpr}} ||<br />
|-<br />
| WF-3720 || rowspan="8" | {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| WF-4720 ||<br />
|-<br />
| WF-4730 ||<br />
|-<br />
| WF-4740 ||<br />
|-<br />
| WF-7210 ||<br />
|-<br />
| WF-7710 ||<br />
|-<br />
| WF-7720 ||<br />
|-<br />
| WF-C869R ||<br />
|-<br />
| XP-205 -207 || {{AUR|epson-inkjet-printer-escpr}} ||<br />
|-<br />
| XP-446 || rowspan="2" | {{AUR|epson-inkjet-printer-escpr}} ||<br />
|-<br />
| XP-630 Series<br />
|-<br />
| XP-5100 || rowspan="4" | {{AUR|epson-inkjet-printer-escpr2}} ||<br />
|-<br />
| XP-6000 ||<br />
|-<br />
| XP-8500 ||<br />
|-<br />
| XP-15000 ||<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
=== Utilities ===<br />
<br />
==== escputil ====<br />
<br />
escputil is part of the {{Pkg|gutenprint}} package, and performs some utility functions on Epson printers such as nozzle cleaning.<br />
<br />
==== mtink ====<br />
<br />
This is a printer status monitor which enables to get the remaining ink quantity, to print test patterns, to reset printer and to clean nozzle. It use an intuitive graphical user interface.<br />
<br />
==== Stylus-toolbox ====<br />
<br />
This is a GUI using escputil and cups drivers. It supports nearly all USB printer of Epson and displays ink quantity, can clean and align print heads and print test patterns.<br />
<br />
===Custom drivers===<br />
<br />
==== Avasys ====<br />
<br />
{{Warning|This section involves installing packages without [[pacman]]. These directions should ideally be automated with a [[PKGBUILD]].}}<br />
"Source" code of the driver is available on the [https://www.avasys.jp avasys website], in Japanese, however it includes a 32 bit binary which will cause problem on 64 bit system.<br />
<br />
* [[Install]] the {{Pkg|psutils}}, {{Pkg|bc}}, {{AUR|libstdc++5}} packages ({{AUR|lib32-libstdc++5}} on 64bit).<br />
* Download the source code of the driver.<br />
* Compile and install the driver. <br />
<br />
$ ./configure --prefix=/usr<br />
$ make<br />
# make install<br />
<br />
If you have any problems on a 64 system, some other lib32 libraries may be required. Please adjust this page if that is the case.<br />
<br />
=== Adding missing paper sizes ===<br />
<br />
Some of the PPD files in {{AUR|epson-inkjet-printer-escpr2}} are missing paper size definitions for media that is supported by the printers and the filter. It is relatively straightforward to add the missing media types to the PPD files.<br />
<br />
To begin, download the PKGBUILD for the {{AUR|epson-inkjet-printer-escpr2}} package, either with an AUR helper or from a snapshot tarball. Once in the directory with the PKGBUILD, download and extract the source of the package by running {{ic|makepkg --nobuild}}.<br />
<br />
Change directory to to {{ic|src/epson-inkjet-printer-escpr2-$PKGVER}}. Open the file {{ic|src/optBase.h}} in a text editor for reference.<br />
<br />
Identify the PPD used by your printer in the {{ic|ppd}} directory. For example, a Workforce 7710 printer uses {{ic|Epson-WF-7710_Series-epson-escpr2-en.ppd}}. Let us call it {{ic|your_ppd_filename}}. Convert the relevant PPD to a PPD compiler source file using the {{ic|ppdi}} utility from the {{Pkg|cups}} package.<br />
<br />
$ ppdi -o your_ppd_filename.drv ppd/your_ppd_filename.ppd<br />
<br />
Open the newly-created {{ic|your_ppd_filename.drv}} in a text editor. Identify the section of the file with a lot of lines starting with {{ic|CustomMedia}}. Duplicate one such line to modify. For example:<br />
<br />
CustomMedia "Legal/US Legal" 612.00 1008.00 8.40 8.40 8.40 8.40 "<</PageSize[612.00 1008.00]/ImagingBBox null>>setpagedevice" "<</PageRegion[612.00 1008.00]/ImagingBBox null>>setpagedevice"<br />
<br />
The pair of numbers {{ic|612.00 1008.00}} represents the width and height of the paper in inches, multiplied by 72. Replace all three instances of these numbers with the dimensions of the paper you want to add. For example to add 11"x17" paper, replace the numbers with {{ic|792.00 1224.00}}.<br />
<br />
The string {{ic|"Legal/US Legal"}} identifies the paper. On the left side of the slash, {{ic|Legal}} is a magic identifier that the filter uses to identify the paper size. Replace it with the one you want to use. Refer to the {{ic|mediaSizeData}} array in {{ic|optBase.h}} for a list of possible values. The string to the right of the slash can be set to any human-readable value.<br />
<br />
If you want to enable borderless printing for a paper size, prefix the magic identifier string you just found with the letter T. So {{ic|Letter}} would become {{ic|TLetter}}. Additionally, change the four numbers {{ic|8.40 8.40 8.40 8.40}} to {{ic|0.00 0.00 0.00 0.00}}.<br />
<br />
For example, I was able to add 11x17 paper to the PPD for a Workforce 7710 by adding the following lines:<br />
<br />
CustomMedia "USB/US B(11x17 in)" 792.00 1224.00 8.40 8.40 8.40 8.40 "<</PageSize[792.00 1224.00]/ImagingBBox null>>setpagedevice" "<</PageRegion[792.00 1224.00]/ImagingBBox null>>setpagedevice"<br />
CustomMedia "TUSB/US B(11x17 in) (Borderless)" 792.00 1224.00 0.00 0.00 0.00 0.00 "<</PageSize[792.00 1224.00]/ImagingBBox null>>setpagedevice" "<</PageRegion[792.00 1224.00]/ImagingBBox null>>setpagedevice"<br />
<br />
Once you have added your custom size, recompile {{ic|your_ppd_filename.drv}} into a PPD file with ppdc (also from {{Pkg|cups}}):<br />
<br />
$ ppdc your_ppd_filename.drv<br />
<br />
This will create a ppd file in the {{ic|ppd}} directory with a file name derived from the {{ic|PCFileName}} parameter in {{ic|your_ppd_filename.drv}}. You can test this file by uploading it to the CUPS web interface, or install it permanently by overwriting the original PPD file and making the package with {{ic|makepkg}}.<br />
<br />
== HP ==<br />
<br />
See also [[CUPS/Troubleshooting#HP issues]].<br />
<br />
Most HP printers will use {{Pkg|hplip}}, some may use {{AUR|hpoj}}, while for multifunction laser printers {{aur|hpuld}} might be required. Some laser printers are also supported by {{AUR|foo2zjs-nightly}}.<br />
<br />
Notice that if {{ic|lpinfo -m}} tells you that the driver "requires proprietary plugin", you need to install {{AUR|hplip-plugin}}.<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| DeskJet 710C || rowspan="8" | {{AUR|pnm2ppa}} ||<br />
|-<br />
| DeskJet 712C ||<br />
|-<br />
| DeskJet 720C ||<br />
|-<br />
| DeskJet 722C ||<br />
|-<br />
| DeskJet 820se ||<br />
|-<br />
| DeskJet 820Cxi ||<br />
|-<br />
| DeskJet 1000Cse ||<br />
|-<br />
| DeskJet 1000Cxi ||<br />
|-<br />
| Envy 6452 series || {{Pkg|hplip}} || Search using mDNS/Bonjour<br />
|-<br />
| Envy 7800 series || {{Pkg|hplip}} || Have not tried [[foomatic]] yet<br />
|-<br />
| LaserJet P1606dn || rowspan="2" | {{Pkg|hplip}} + {{aur|hplip-plugin}} || Or {{aur|foo2zjs-nightly}}, or [[CUPS#CUPS|AirPrint]].<br />
|-<br />
| LaserJet Pro MFP M126nw ||<br />
|-<br />
| LaserJet Pro MFP M281fdw || rowspan="2" | {{Pkg|hplip}} || No proprietary drivers as of 2019-04-18 <br />
|-<br />
| Photosmart 2575 || Or use the hpijs driver in [[foomatic]].<br />
|-<br />
| HP LaserJet MFP M433 || rowspan="7" | {{aur|hpuld}} ||<br />
|-<br />
| HP LaserJet MFP M436 ||<br />
|-<br />
| HP LaserJet MFP M72625 72630 ||<br />
|-<br />
| Laser 10x Series ||<br />
|-<br />
| Laser MFP 13x Series ||<br />
|-<br />
| Color Laser 15x Series ||<br />
|-<br />
| Color Laser MFP 17x Series ||<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
=== HPLIP ===<br />
<br />
{{Note|As of hplip v3.17.11 hpijs is no longer available. If you have printers using hpijs they will fail to print. You must modify them and select the new hpcups driver instead.}}<br />
<br />
{{Pkg|hplip}} provides drivers for HP DeskJet, OfficeJet, Photosmart, Business Inkjet, and some LaserJet printers, and also provides an easy to use setup tool. See https://developers.hp.com/hp-linux-imaging-and-printing/supported_devices/index for the list of supported printers. hplip requires {{Pkg|python-pyqt5}} to run the GUI qt frontend. hp-setup requires [[CUPS]] to be installed and {{ic|cups.service}} to be started to save the printer.<br />
<br />
To run the setup tool with the GUI qt frontend:<br />
<br />
$ hp-setup -u<br />
<br />
To run the setup tool with the command line frontend:<br />
<br />
$ hp-setup -i<br />
<br />
To set up directly the configuration of a network connected HP printer:<br />
<br />
$ hp-setup -i ''ip_address''<br />
<br />
To run systray spool manager:<br />
<br />
$ hp-systray<br />
<br />
To generate a URI for a given ip address:<br />
<br />
# hp-makeuri ''<ip address>''<br />
<br />
PPD files are in {{ic|/usr/share/ppd/HP/}}.<br />
<br />
If your printer is [https://developers.hp.com/hp-linux-imaging-and-printing/binary_plugin.html listed as requiring a binary plugin], install the {{AUR|hplip-plugin}} package from [[AUR]].<br />
If the binary plugin {{AUR|hplip-plugin}} is a requirement you will need to [[start]] the {{ic|cups.service}} before the PPD is recognized by {{Pkg|hplip}}. If that does not work, reboot and log in with the printer ''off''. Then switch it on and run a test print.<br />
<br />
{{Note|Since at least with {{Pkg|hplip}} v3.22.10, `hp-setup` crashes when it detects `hpfax://` type of printer, with the message `Unable to communicate with the device. Please check the device and try again`. This is likely due to the missing {{AUR|hplip-plugin}}, but can be bypassed by disabeling fax support on the printer itself.<br />
<br />
{{Note|{{Pkg|hplip}} depends on {{Pkg|foomatic-db-engine}} which prevents the drivers list from appearing when a printer is added to CUPS via the web user interface (following error : "Unable to get list of printer drivers"). Possible workarounds:<br />
* '''Either:''' Install {{Pkg|hplip}} first, then retrieve the PPD file that matches your printer from {{ic|/usr/share/ppd/HP/}}. Next, remove {{Pkg|hplip}} entirely as well as any unnecessary dependencies. Finally, install the printer manually using the CUPS web UI, selecting the PPD file you retrieved, and then re-install {{Pkg|hplip}}. After a reboot, you should have a fully working printer.<br />
* '''Or:''' Remove {{Pkg|hplip}}, {{Pkg|foomatic-db}} and {{Pkg|foomatic-db-engine}} along with any unnecessary dependencies. Reinstall {{Pkg|hplip}} and restart CUPS. Install your printer using the CUPS web UI, which should now be able to find the drivers automatically. No reboot needed.}}<br />
<br />
=== HPULD ===<br />
<br />
See [[Debian:CUPSPrintQueues#hpuld]] for more information.<br />
<br />
The package {{AUR|hpuld}} collects the sparse "HP + ULD" packages into one single package.<br />
<br />
=== foo2zjs ===<br />
<br />
[https://web.archive.org/web/20210129024712/http://foo2zjs.rkkda.com/ foo2zjs] supports some HP LaserJet printers. As of June 2018 the hplip package interferes with {{aur|foo2zjs-nightly}}, as described at [https://bbs.archlinux.org/viewtopic.php?pid=1662809 this forum post] and {{Bug|58815}}.<br />
<br />
== Kodak ==<br />
<br />
{{AUR|c2esp}} is free software. [https://sourceforge.net/projects/cupsdriverkodak/ Upstream notes] it is likely to work on all ESP and Hero printers/scanners.<br />
<br />
== Konica Minolta ==<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| Minolta Magicolor 1600W || rowspan=7 | [[foomatic]] ||<br />
|-<br />
| Minolta Magicolor 1680MF ||<br />
|-<br />
| Minolta Magicolor 1690MF ||<br />
|-<br />
| Minolta Magicolor 2480MF ||<br />
|-<br />
| Minolta Magicolor 2490MF ||<br />
|-<br />
| Minolta Magicolor 2530DL ||<br />
|-<br />
| Minolta Magicolor 4690MF ||<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
=== foo2zjs ===<br />
<br />
[[#foo2zjs]], mentioned above for supporting some HP printers, also support some Minolta printers.<br />
<br />
== Lexmark ==<br />
<br />
Note that most Lexmark printers are now supported by CUPS without needing further installation. See also [[SANE/Scanner-specific problems#Lexmark]] for Lexmark scanners issues.<br />
<br />
=== Utilities ===<br />
<br />
Lexmark provides a utility called ''lexijtools'' with the drivers.<br />
<br />
=== Custom drivers ===<br />
<br />
{{Out of date|This section was written before the i686 architecture stopped being supported. As such, it provides only an example with an i686 packages and needs to be updated by taking [[32-bit package guidelines]] into consideration.}}<br />
<br />
Lexmark does provide Linux drivers for all their hardware.<br />
The following packages are required:<br />
<br />
* {{Pkg|cups}}<br />
* {{Pkg|sane}}<br />
* {{Pkg|ncurses}}<br />
* {{Pkg|libusb}}<br />
* {{Pkg|libxext}}<br />
* {{Pkg|libxtst}}<br />
* {{Pkg|libxi}}<br />
* {{AUR|libstdc++5}}<br />
* {{Pkg|krb5}}<br />
* {{Pkg|lua}} (for the automated installer)<br />
* [[Java]] (for the automated installer, and some of the Lexmark tools)<br />
<br />
The drivers will need to be [http://support.lexmark.com/index?page=driversdownloads downloaded]{{Dead link|2022|09|17|status=404}} from Lexmark's website. Preferably, create a package (see [[Creating packages]]) and install it. Here is a basic [[PKGBUILD]] that still needs work but will give an idea of what is required.<br />
<br />
{{hc|PKGBUILD|<nowiki><br />
# Contributor: Todd Partridge (Gen2ly) toddrpartridge (at) yahoo<br />
<br />
pkgname=cups-lexmark-Z2300-2600<br />
pkgver=1<br />
pkgrel=1<br />
pkgdesc="Lexmark Z2300 and 2600 Series printer driver for cups"<br />
arch=('i686')<br />
url="http://www.lexmark.com/"<br />
license=('custom')<br />
depends=('cups' 'glibc' 'ncurses' 'libusb' 'libxext' 'libxtst' 'libxi' 'libstdc++5' 'krb5' 'lua' 'java-runtime')<br />
conflicts=('z600' 'cjlz35le-cups' 'cups-lexmark-700')<br />
source=(lexmark-inkjet-08-driver-1.0-1.i386.tar.gz.sh)<br />
md5sums=(3c37eb87e3dad4853bf29344f9695134)<br />
<br />
package() {<br />
# Extract installer<br />
sh lexmark-inkjet-08-driver-1.0-1.i386.tar.gz.sh --target Installer-Files<br />
cd Installer-Files<br />
mkdir Driver<br />
tar xvvf instarchive_all --lzma -C Driver/<br />
cd Driver<br />
tar xv lexmark-inkjet-08-driver-1.0-1.i386.tar.gz -C $pkgdir<br />
}<br />
</nowiki>}}<br />
<br />
Keep in mind you can use the automated installer but doing so will leave the resulting changes untracked. The PPD will be installed into {{ic|/usr/local/lexmark/lxk08/etc/}} or similar, depending on the printer model.<br />
<br />
== Oki ==<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| C110|| [[foomatic]] ||<br />
|-<br />
| MC561|| [[CUPS#Foomatic|foomatic-db-nonfree]] ||<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
== Ricoh ==<br />
<br />
Install {{AUR|openprinting-ppds-pxlmono-ricoh}} if your device is black and white, or {{AUR|openprinting-ppds-pxlcolor-ricoh}} if it is color. Note that Ricoh copiers are sometimes branded as Savin, Gestetner, Lanier, Rex-Rotary, Nashuatec, and/or IKON. So, if you have a device bearing one of these brands, it may be supported by these drivers as well.<br />
<br />
* [https://www.openprinting.org/driver/pxlmono-Ricoh List of supported black and white models]<br />
* [https://www.openprinting.org/driver/pxlcolor-Ricoh List of supported color models]<br />
<br />
For cheap [[Wikipedia:en:Graphics_Device_Interface#GDI printers|GDI-only winprinters]], which do not support PCL (Ricoh series SP100 and SP200) try out {{AUR|ricoh-sp100-git}}.<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| SP 112 || {{AUR|ricoh-sp100-git}} ||<br />
|-<br />
| SP 201n || {{AUR|ricoh-sp100-git}} ||<br />
|-<br />
| 213W || ''Generic PCL Laser'' || Obtain a WPS code by holding down the wifi button for 2 seconds, then hitting the stop/start button.<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
== Samsung ==<br />
<br />
Since 2016, or 2017, Samsung is no longer in the printers/scanners business. As of 2019, HP partially support some of Samsung printers/scanners. Before 2016, Samsung was a major player. Which is why there are still many Samsung machines around. In addition, Linux, and cups, keep evolving. The bottom line of all this is that supporting Samsung products is at a flux.<br />
<br />
A major site for information about Samsung printers/scanners is [https://www.bchemnet.com/suldr/ Samsung Unified Linux Driver Repository]. Despite its name, it is not affiliated by Samsung. Neither it is devoted only to {{AUR|samsung-unified-driver}}. {{ic|samsung-unified-driver}}, on the other hand, is close source by Samsung. It also encompass Windows and Mac. It might be the first stop to get a driver for a Samsung printer and scanner as it, or was, claim to support practically every one of these. Note that {{ic|samsung-unified-driver}} includes software that can stand on its own, not tied to cups. If you can not get the printer to work with cups, you might try this route.<br />
<br />
That said, there are more options. An overview is at [https://www.bchemnet.com/suldr/alternatives.html alternatives].<br />
<br />
* Out of CJX-XXX series, at least CJX-1000, CJX-1050W, and CJX-2000FW are reported to work with {{AUR|c2esp}}, even though {{ic|c2esp}} is supposedly for Kodak products. <br />
* For [https://ghostarchive.org/archive/vj6tA Samsung Printer Language], there is {{Pkg|splix}}. For a list of models that are supported, see its [http://splix.ap2c.org/ home page]. Other SPL Samsung printers, even tough not in that list, might work with {{ic|splix}}. <br />
* QPDL (Quick Page Description Language) printers, some of which are supported by {{ic|splix}}, are also supported by by {{ic|foo2qpdl}}, provided by the [[#foo2zjs]] package. A list of known to work models is [https://web.archive.org/web/20210312142508/http://www.foo2qpdl.rkkda.com/ here].<br />
All of {{ic|c2esp}}, {{ic|splix}} and {{ic|foo2zjs}} are free software.<br />
<br />
You should also note that many Samsung printers support PostScript. Chances are that it will work with CUPS generic postscript printer, especially if it is only black & white and only printer, without a scanner added to it. Generic driver may be missing functionality or limited, for example in their support for duplex, color control, and resolution settings, and print quality may be lower.<br />
<br />
== Xerox or FujiXerox ==<br />
<br />
{| class="wikitable"<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|-<br />
| DocuPrint 203A || {{Pkg|hplip}} || Using the '''DocuPrint P8e(hpijs)''' driver, or the Brother driver on FujiXerox's website (see [[#Brother]] for more information on how to install custom Brother drivers).<br />
|-<br />
| Phaser 3100MFP || Install Xerox's driver || See [[#Phaser 3100MFP]] for more instructions.<br />
|-<br />
| Phaser 6115MFP || [[foomatic]] ||<br />
|-<br />
| Phaser 6121MFP || [[foomatic]] ||<br />
|-<br />
| Xerox Workcentre 3119 || {{Pkg|splix}} || Since Samsung SCX-4200 is the rebranded Xerox 3119, splix package works for both<br />
|-<br />
! Printer<br />
! Driver/filter<br />
! Notes<br />
|}<br />
<br />
=== Custom drivers ===<br />
<br />
==== Phaser 3100MFP ====<br />
<br />
{{Warning|This section involves installing packages without [[pacman]]. These directions should ideally be automated with a [[PKGBUILD]].}}<br />
<br />
Once you have downloaded the drivers, execute the driver installer and accept the licence:<br />
<br />
# cd printer<br />
# ./XeroxPhaser3100.install<br />
<br />
Note that the driver is 32 bit, so some 32 bit libraries will be required on an x86_64 system: {{pkg|lib32-libpng12}}, {{pkg|lib32-zlib}}, {{pkg|lib32-libjpeg6-turbo}}, {{pkg|lib32-libcups}}, {{pkg|lib32-libxext}}, {{pkg|lib32-libx11}}, {{pkg|lib32-gcc-libs}}, {{aur|lib32-libstdc++5}}<br />
<br />
For the scanner, create an {{ic|/etc/sane.d}} directory if it does not already exist, because it is needed by the installer:<br />
<br />
# mkdir -p /etc/sane.d<br />
<br />
Now install the driver:<br />
<br />
# cd scanner/<br />
# ./XeroxPhaser3100sc.install<br />
<br />
Again, on an x86_64 install, 32 bit libraries will be needed.<br />
<br />
==== Phaser 6000B ====<br />
<br />
[[Install]] the [https://github.com/aur-archive/xerox-phaser-6010 xerox-phaser-6010] package (archived from the AUR).<br />
The driver may require older versions of {{Pkg|nettle}} and {{Pkg|gnutls}} to be installed, since the binary blob linked against older versions of the shared libraries provided by those packages. The oldest known-good versions are {{ic|nettle-2.7.1-1}} and {{ic|gnutls-3.3.13-1}}.<br />
<br />
==== Phaser 6125N ====<br />
<br />
{{Warning|This section involves installing packages without [[pacman]]. These directions should ideally be automated with a [[PKGBUILD]].}}<br />
<br />
FujiXerox does not support Linux on this model. An old rpm [https://onlinesupport.fujixerox.com/tiles/common/hc_drivers_download.jsp?system=%27Linux%27&shortdesc=null&xcrealpath=http://www.fujixeroxprinters.com/downloads/uploaded/dpc525a_linux_.0.0.tar_81c2.zip is available]{{Dead link|2022|09|17|status=SSL error}} but does not seem to work.<br />
<br />
A slightly adapted [https://rickvanderzwet.nl/trac/personal/wiki/XeroxPhaser6125N custom driver] has been found to work out of the box.<br />
<br />
To install the tarball, run:<br />
<br />
# tar -C / --keep-newer-files -xvzf cups-xerox-phaser-6125n-1.0.0.tar.gz</div>Oliverhttps://wiki.archlinux.org/index.php?title=User:Oliver/New_Install_Guide&diff=700031User:Oliver/New Install Guide2021-10-26T20:02:07Z<p>Oliver: Do non-chroot dependent tasks first, so chroot is only done where it is actually needed.</p>
<hr />
<div>{{Unsupported|26 October 2021}}<br />
[[bg:Installation guide]]<br />
[[cs:Installation guide]]<br />
[[de:Arch Install Scripts]]<br />
[[el:Installation guide]]<br />
[[es:Installation guide]]<br />
[[fa:راهنمای تازهکاران]]<br />
[[fi:Installation guide]]<br />
[[fr:Installation guide]]<br />
[[hu:Installation guide]]<br />
[[it:Installation guide]]<br />
[[ja:インストールガイド]]<br />
[[ko:Installation guide]]<br />
[[lt:Installation guide]]<br />
[[pl:Installation guide]]<br />
[[pt:Installation guide]]<br />
[[ru:Installation guide]]<br />
[[sv:Installation guide]]<br />
[[th:Installation guide]]<br />
[[tr:Installation guide]]<br />
[[uk:Installation guide]]<br />
[[zh-hans:Installation guide]]<br />
[[zh-hant:Installation guide]]<br />
This document is a guide for installing [[Arch Linux]] using the live system booted from an installation medium made from an official installation image. The installation medium provides accessibility features which are described on the page [[Install Arch Linux with accessibility options]]. For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation.[https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html] A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available.<br />
<br />
== Pre-installation ==<br />
<br />
=== Acquire an installation image ===<br />
<br />
Visit the [https://archlinux.org/download/ Download] page and, depending on how you want to boot, acquire the ISO file or a netboot image, and the respective [[GnuPG]] signature.<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 [https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html serve malicious images]. <br />
<br />
On a system with [[GnuPG]] installed, do this by downloading the ''PGP signature'' (under ''Checksums'' in the [https://archlinux.org/download/ Download] page) to the ISO directory, and [[GnuPG#Verify a signature|verifying]] it with: <br />
<br />
$ gpg --keyserver-options auto-key-retrieve --verify archlinux-''version''-x86_64.iso.sig<br />
<br />
Alternatively, from an existing Arch Linux installation run:<br />
<br />
$ pacman-key -v archlinux-''version''-x86_64.iso.sig<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://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 />
=== Prepare an installation medium ===<br />
<br />
The installation image can be supplied to the target machine via a [[USB flash installation medium|USB flash drive]], an [[Optical disc drive#Burning|optical disc]] or a network with [[PXE]]: follow the appropriate article to prepare yourself an installation medium from the chosen image.<br />
<br />
=== Boot the live environment ===<br />
<br />
{{Note|Arch Linux installation images do not support Secure Boot. You will need to [[Unified Extensible Firmware Interface/Secure Boot#Disabling Secure Boot|disable Secure Boot]] to boot the installation medium. If desired, [[Secure Boot]] can be set up after completing the installation.}}<br />
<br />
# Point the current boot device to the one which has the Arch Linux installation medium. Typically it is achieved by pressing a key during the [[Wikipedia:Power-on self test|POST]] phase, as indicated on the splash screen. Refer to your motherboard's manual for details.<br />
# When the installation medium's boot loader menu appears, select ''Arch Linux install medium'' and press {{ic|Enter}} to enter the installation environment. {{Tip|The installation image uses [[systemd-boot]] for booting in UEFI mode and [[syslinux]] for booting in BIOS mode. See [https://gitlab.archlinux.org/mkinitcpio/mkinitcpio-archiso/blob/master/docs/README.bootparams README.bootparams] for a list of [[Kernel parameters#Configuration|boot parameters]].}}<br />
# You will be logged in on the first [[Wikipedia:Virtual console|virtual console]] as the root user, and presented with a [[Zsh]] shell prompt.<br />
<br />
To switch to a different console—for example, to view this guide with [https://lynx.invisible-island.net/lynx_help/Lynx_users_guide.html Lynx] alongside the installation—use the {{ic|Alt+''arrow''}} [[Keyboard shortcuts|shortcut]]. To [[textedit|edit]] configuration files, {{man|1|mcedit}}, [[nano#Usage|nano]] and [[vim#Usage|vim]] are available. See [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64 packages.x86_64] for a list of the packages included in the installation medium.<br />
<br />
=== Set the console keyboard layout ===<br />
<br />
The default [[console keymap]] is [[Wikipedia:File:KB United States-NoAltGr.svg|US]]. Available layouts can be listed with:<br />
<br />
# ls /usr/share/kbd/keymaps/**/*.map.gz<br />
<br />
To modify the layout, append a corresponding file name to {{man|1|loadkeys}}, omitting path and file extension. For example, to set a [[Wikipedia:File:KB Germany.svg|German]] keyboard layout:<br />
<br />
# loadkeys de-latin1<br />
<br />
[[Console fonts]] are located in {{ic|/usr/share/kbd/consolefonts/}} and can likewise be set with {{man|8|setfont}}.<br />
<br />
=== Verify the boot mode ===<br />
<br />
To verify the boot mode, list the [[efivars]] directory:<br />
<br />
# ls /sys/firmware/efi/efivars<br />
<br />
If the command shows the directory without error, then the system is booted in UEFI mode. If the directory does not exist, the system may be booted in [[Wikipedia:BIOS|BIOS]] (or [[Wikipedia:Compatibility Support Module|CSM]]) mode. If the system did not boot in the mode you desired, refer to your motherboard's manual.<br />
<br />
=== Connect to the internet ===<br />
<br />
To set up a network connection in the live environment, go through the following steps:<br />
<br />
* Ensure your [[network interface]] is listed and enabled, for example with {{man|8|ip-link}}: {{bc|# ip link}}<br />
* For wireless and WWAN, make sure the card is not blocked with [[rfkill]].<br />
* Connect to the network:<br />
** Ethernet—plug in the cable.<br />
** Wi-Fi—authenticate to the wireless network using [[iwctl]].<br />
** Mobile broadband modem—connect to the mobile network with the [[mmcli]] utility.<br />
* Configure your network connection:<br />
** [[DHCP]]: dynamic IP address and DNS server assignment (provided by [[systemd-networkd]] and [[systemd-resolved]]) should work out of the box for [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-ethernet.network Ethernet], [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wlan.network WLAN] and [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wwan.network WWAN] network interfaces.<br />
** Static IP address: follow [[Network configuration#Static IP address]].<br />
* The connection may be verified with [[Wikipedia:ping (networking utility)|ping]]: {{bc|# ping archlinux.org}}<br />
<br />
{{Note|In the installation image, [[systemd-networkd]], [[systemd-resolved]], [[iwd]] and [[ModemManager]] are preconfigured and enabled by default. That will not be the case for the installed system.}}<br />
<br />
=== Update the system clock ===<br />
<br />
Use {{man|1|timedatectl}} to ensure the system clock is accurate:<br />
<br />
# timedatectl set-ntp true<br />
<br />
To check the service status, use {{ic|timedatectl status}}.<br />
<br />
=== Partition the disks ===<br />
<br />
When recognized by the live system, disks are assigned to a [[block device]] such as {{ic|/dev/sda}}, {{ic|/dev/nvme0n1}} or {{ic|/dev/mmcblk0}}. To identify these devices, use [[lsblk]] or ''fdisk''.<br />
<br />
# fdisk -l<br />
<br />
Results ending in {{ic|rom}}, {{ic|loop}} or {{ic|airoot}} may be ignored.<br />
<br />
The following [[partition]]s are '''required''' for a chosen device:<br />
<br />
* One partition for the [[Wikipedia:Root directory|root directory]] {{ic|/}}.<br />
* For booting in [[UEFI]] mode: an [[EFI system partition]].<br />
<br />
If you want to create any stacked block devices for [[LVM]], [[dm-crypt|system encryption]] or [[RAID]], do it now.<br />
<br />
Use [[fdisk]] or [[parted]] to modify partition tables. For example:<br />
<br />
# fdisk ''/dev/the_disk_to_be_partitioned''<br />
<br />
{{Note|<br />
* [[Swap]] space can be set on a [[swap file]] for file systems supporting it.<br />
* If the disk from which you want to boot [[EFI system partition#Check for an existing partition|already has an EFI system partition]], do not create another one, but use the existing partition instead.<br />
}}<br />
<br />
==== Example layouts ====<br />
<br />
{| class="wikitable"<br />
|+ BIOS with [[MBR]]<br />
|-<br />
! Mount point<br />
! Partition<br />
! [[Wikipedia:Partition type|Partition type]]<br />
! Suggested size<br />
|-<br />
| {{ic|[SWAP]}}<br />
| {{ic|/dev/''swap_partition''}}<br />
| Linux swap<br />
| More than 512 MiB<br />
|-<br />
| {{ic|/target}}<br />
| {{ic|/dev/''root_partition''}}<br />
| Linux<br />
| Remainder of the device<br />
|}<br />
<br />
{| class="wikitable"<br />
|+ UEFI with [[GPT]]<br />
|-<br />
! Mount point<br />
! Partition<br />
! [[Wikipedia:GUID Partition Table#Partition type GUIDs|Partition type]]<br />
! Suggested size<br />
|-<br />
| {{ic|/target/boot}} or {{ic|/target/efi}}<sup>1</sup><br />
| {{ic|/dev/''efi_system_partition''}}<br />
| [[EFI system partition]]<br />
| At least 260 MiB<br />
|-<br />
| {{ic|[SWAP]}}<br />
| {{ic|/dev/''swap_partition''}}<br />
| Linux swap<br />
| More than 512 MiB<br />
|-<br />
| {{ic|/target}}<br />
| {{ic|/dev/''root_partition''}}<br />
| Linux x86-64 root (/)<br />
| Remainder of the device<br />
|}<br />
<br />
# {{ic|/target/efi}} should only be considered if the used boot loader is capable of loading the kernel and initramfs images from the root volume. See the warning in [[Arch boot process#Boot loader]].<br />
<br />
See also [[Partitioning#Example layouts]].<br />
<br />
=== Format the partitions ===<br />
<br />
Once the partitions have been created, each newly created partition must be formatted with an appropriate [[file system]]. For example, to create an Ext4 file system on {{ic|/dev/''root_partition''}}, run:<br />
<br />
# mkfs.ext4 /dev/''root_partition''<br />
<br />
If you created a partition for [[swap]], initialize it with {{man|8|mkswap}}:<br />
<br />
# mkswap /dev/''swap_partition''<br />
<br />
See [[File systems#Create a file system]] for details.<br />
<br />
{{Note|For stacked block devices replace {{ic|/dev/''*_partition''}} with the appropriate block device path.}}<br />
<br />
=== Mount the file systems ===<br />
<br />
[[Mount]] the root volume to {{ic|/target}}. For example, if the root volume is {{ic|/dev/''root_partition''}}:<br />
<br />
# mdkir -p /target<br />
# mount /dev/''root_partition'' /target<br />
<br />
Create any remaining mount points (such as {{ic|/target/efi}}) using {{man|1|mkdir}} and mount their corresponding volumes. <br />
<br />
If you created a [[swap]] volume, enable it with {{man|8|swapon}}:<br />
<br />
# swapon /dev/''swap_partition''<br />
<br />
{{man|8|genfstab}} will later detect mounted file systems and swap space.<br />
<br />
== Installation ==<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. On the live system, after connecting to the internet, [[reflector]] updates the mirror list by choosing 20 most recently synchronized HTTPS mirrors and sorting them by download rate.[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/xdg/reflector/reflector.conf]<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. You may want to inspect the file to see if it is satisfactory. If it is not, [[textedit|edit]] the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
Use the {{man|8|pacstrap}} script to install the {{Pkg|base}} package, Linux [[kernel]] and firmware for common hardware:<br />
<br />
# pacstrap /target base linux linux-firmware<br />
<br />
{{Tip|<br />
* You can substitute {{Pkg|linux}} for a [[kernel]] package of your choice, or you could omit it entirely when installing in a [[Wikipedia:Container (virtualization)|container]].<br />
* You could omit the installation of the firmware package when installing in a virtual machine or container.<br />
}}<br />
<br />
The {{Pkg|base}} package does not include all tools from the live installation, so installing other packages may be necessary for a fully functional base system. In particular, consider installing:<br />
<br />
* userspace utilities for the management of [[file systems]] that will be used on the system,<br />
* utilities for accessing [[RAID]] or [[LVM]] partitions,<br />
* specific firmware for other devices not included in {{Pkg|linux-firmware}} (e.g. {{Pkg|sof-firmware}} for [[Advanced Linux Sound Architecture#ALSA firmware|sound cards]]),<br />
* software necessary for [[networking]],<br />
* a [[text editor]],<br />
* packages for accessing documentation in [[man]] and [[info]] pages: {{Pkg|man-db}}, {{Pkg|man-pages}} and {{Pkg|texinfo}}.<br />
<br />
To [[install]] other packages or package groups, append the names to the ''pacstrap'' command above (space separated) or use [[pacman]] while [[#Chroot|chrooted into the new system]]. For comparison, packages available in the live system can be found in [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64 packages.x86_64].<br />
<br />
== Configure the system ==<br />
<br />
=== Fstab ===<br />
<br />
Generate an [[fstab]] file (use {{ic|-U}} or {{ic|-L}} to define by [[UUID]] or labels, respectively):<br />
<br />
# genfstab -U /target >> /target/etc/fstab<br />
<br />
Check the resulting {{ic|/target/etc/fstab}} file, and [[textedit|edit]] it in case of errors.<br />
<br />
=== Time zone ===<br />
<br />
Set the [[time zone]]:<br />
<br />
# ln -sf /usr/share/zoneinfo/''Region''/''City'' /target/etc/localtime<br />
<br />
Run {{man|8|hwclock}} to generate {{ic|/target/etc/adjtime}}:<br />
<br />
# hwclock --systohc --adjfile /target/etc/adjtime<br />
<br />
This command assumes the hardware clock is set to [[Wikipedia:UTC|UTC]]. See [[System time#Time standard]] for details.<br />
<br />
=== Network configuration ===<br />
<br />
[[Create]] the [[hostname]] file:<br />
<br />
{{hc|/target/etc/hostname|<br />
''myhostname''<br />
}}<br />
<br />
Complete the [[network configuration]] for the newly installed environment. That may include installing suitable [[network management]] software.<br />
<br />
=== Chroot ===<br />
<br />
[[Change root]] into the new system:<br />
<br />
# arch-chroot /target<br />
<br />
=== Localization ===<br />
<br />
[[textedit|Edit]] {{ic|/etc/locale.gen}} and uncomment {{ic|en_US.UTF-8 UTF-8}} and other needed [[locale]]s. Generate the locales by running:<br />
<br />
# locale-gen<br />
<br />
[[Create]] the {{man|5|locale.conf}} file, and [[Locale#Setting the system locale|set the LANG variable]] accordingly:<br />
<br />
{{hc|1=/etc/locale.conf|2=<br />
LANG=''en_US.UTF-8''<br />
}}<br />
<br />
If you [[#Set the console keyboard layout|set the console keyboard layout]], make the changes persistent in {{man|5|vconsole.conf}}:<br />
<br />
{{hc|1=/etc/vconsole.conf|2=<br />
KEYMAP=''de-latin1''<br />
}}<br />
<br />
=== Initramfs ===<br />
<br />
Creating a new ''initramfs'' is usually not required, because [[mkinitcpio]] was run on installation of the [[kernel]] package with ''pacstrap''.<br />
<br />
For [[Install Arch Linux on LVM#Adding mkinitcpio hooks|LVM]], [[dm-crypt|system encryption]] or [[RAID#Configure mkinitcpio|RAID]], modify {{man|5|mkinitcpio.conf}} and recreate the initramfs image:<br />
<br />
# mkinitcpio -P<br />
<br />
=== Root password ===<br />
<br />
Set the root [[password]]:<br />
<br />
# passwd<br />
<br />
=== Boot loader ===<br />
<br />
Choose and install a Linux-capable [[boot loader]]. If you have an Intel or AMD CPU, enable [[microcode]] updates in addition.<br />
<br />
== Reboot ==<br />
<br />
Exit the chroot environment by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R /target}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
Finally, restart the machine by typing {{ic|reboot}}: any partitions still mounted will be automatically unmounted by ''systemd''. Remember to remove the installation medium and then login into the new system with the root account.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like creating unprivileged user accounts, setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_via_Docker&diff=700028Install Arch Linux via Docker2021-10-26T19:39:41Z<p>Oliver: Improve readability and help the user jump between this guide and the official installation guide.</p>
<hr />
<div>[[Category:Installation process]]<br />
{{Style|Formatting does not comply to the guidelines, see [[Help:Style]].}}<br />
<br />
This document is a guide for installing [[Arch Linux]] using the official [Arch Linux docker](https://hub.docker.com/_/archlinux). For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation [https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html]. A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available. Furthermore a working [[Docker]] setup on the host is required. While technically it is certainly possible to use any qemu supported host to install Arch with, this guide will not cover this however.<br />
<br />
== Pre-installation ==<br />
<br />
This guide assumes that the host system is already pre-configured with regards to normally expected things. E.g. the time is setup correctly, internet connection is working normally, EFI mode if required is setup correctly etc.<br />
<br />
=== Prepare an installation medium ===<br />
<br />
The installation requires a target directory to which Arch Linux will be installed. Any writable directory can be used, but it is quite likely that the target directory has a partition or volume mounted that will server as the root disk.<br />
<br />
==== Full disk partitions ====<br />
<br />
If a full disk is being used as a target, it may need to be formatted. For details see [[Installation guide#Partition the disks]] as the same partitioning instructions and order can be followed from there. All the same restrictions and requirements as from there apply as well.<br />
<br />
Likewise, the new disk will also needed to be formatted. The instructions from [[Installation guide#Format the partitions]] can be used for this as well.<br />
<br />
==== Volumes ====<br />
<br />
When using filesystems such as [[btrfs]] or zfs, filesystem volumes are an option to use. Depending on what filesystem is used, creating them uses their own list of commands. In this guide, btrfs will be used as an example.<br />
<br />
First, a root volume for Arch Linux is created. This command assumes the current working directory is the btrfs root volume (subvolid=5), but anywhere could be used. If a different location is used, within an existing hierarchy, keep this in mind when later defining fstab and similar. Also note, that as the Arch Linux specific volume is created on a mounted (root) volume, it could be the case that the underlying stack is using (full)disk encryption.<br />
<br />
# btrfs subvolume create "arch_root"<br />
<br />
{{Note|To get the root volume, mount the btrfs with the {{ic|1=subvolid=5}} option.}}<br />
<br />
=== Mount the file systems ===<br />
<br />
The following section assumes the location Arch Linux will be installed into ''/tmp/target''. It is thus required that the partition is thus mounted there. Using a btrfs subvolume called '''arch_root''', with ''autodefrag'' and ''LZO compression'' enabled would look as:<br />
<br />
# mkdir -p /tmp/target<br />
# mount /dev/''disk'' /tmp/target -o subvol=arch_root,compress=lzo,autodefrag<br />
<br />
The instructions from [[Installation guide#Mount the file systems]] can be used for this as well.<br />
<br />
== Installation ==<br />
<br />
=== Launching the container ===<br />
<br />
The remainder of the installation will be done inside a docker container, abbreviated with ADC, Arch Docker Container.<br />
<br />
# docker run \<br />
--env PS1="ADC(\#)[\d \T:\w]\\$ " \<br />
--interactive \<br />
--privileged \<br />
--rm \<br />
--tty \<br />
--volume "/tmp/target:/target" \<br />
"index.docker.io/library/archlinux:latest" /bin/sh<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. In the docker container we first install [[reflector]], which updates the mirror list by choosing 70 most recently synchronized HTTPS mirrors and sorting them by download rate. [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/system/reflector.service]<br />
First we have to [[install]] [[reflector]] in the docker container to be able to use it.<br />
<br />
# reflector [--country <country>] \<br />
--latest 5 \<br />
--protocol http,https \<br />
--save "/etc/pacman.d/mirrorlist" \<br />
--sort rate<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. Ensure to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
To be able to start the installation, the {{Pkg|arch-install-scripts}} package must be installed into the Docker image first and once completed, the official installation guide can be followed starting with the section [[Installation guide#Install essential packages]].<br />
<br />
Return to this guide before executing the '''Reboot''' step from the section [[Installation guide#Reboot]] to instead continue with the [[Install_Arch_Linux_via_Docker#Reboot]] below.<br />
<br />
== Reboot ==<br />
<br />
Exit the docker container by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R "/target"}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
With a correctly setup boot loader, a reboot should now be possible into the freshly installed Arch Linux.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=User_talk:Lahwaacz&diff=700026User talk:Lahwaacz2021-10-26T18:56:48Z<p>Oliver: /* Install Arch Linux via Docker */</p>
<hr />
<div>== bot checking links after move ==<br />
<br />
Hi, re [[Talk:Touchpad Synaptics#adding libinput alternative]]. [[Touchpad Synaptics]] has 100+ backlinks and the more important ones - a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of [[Touchpad Synaptics]] and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:36, 26 September 2015 (UTC)<br />
<br />
:Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a [[UUID]] page, which was later generalized and renamed to [[Persistent block device naming]] and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace <nowiki>[[pacman|Install]]</nowiki> with <nowiki>[[Install]]</nowiki> etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:01, 26 September 2015 (UTC)<br />
<br />
::Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [https://wiki.archlinux.org/index.php/Special:WhatLinksHere/Beginners'_Guide]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:02, 26 September 2015 (UTC)<br />
<br />
== mkosi ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=Systemd-nspawn&diff=0&oldid=491975 revert]: You can use mkosi also to create a container/directory tree (-t directory). So it can do the same and more. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 11:33, 1 October 2017 (UTC)<br />
<br />
:Alright, how is the "more" relevant to systemd-nspawn though? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:30, 3 October 2017 (UTC)<br />
<br />
::Hi, mkosi let's you create images (or directory trees) of various different distributions and allows you to do things like setting the root-password or installing additional packages. systemd-nspawn alows you to boot such images/directory trees. So I thought mentioning mkosi as alternative to manually creating a container with pacstrap or debootstrap would be worth it. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 22:23, 5 October 2017 (UTC)<br />
<br />
== Waking from suspend with USB device ==<br />
<br />
Hi Lahwaacz, thanks for your input on this topic.<br />
Can you help me a bit further, I know the USB host controller and the USB device are different things but I thought that enabling the host controller was not necessary anymore, see [https://www.spinics.net/lists/linux-usb/msg53661.html].<br />
In my case all the {{ic|driver/*/power/wakeup}} are all enabled by default and the {{ic|/proc/acpi/wakeup}} as well.<br />
Anyway I have added a step in my explanations to identify the path awaiting for more clarity.<br />
<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 21:57, 16 January 2018 (UTC)<br />
<br />
:Hi, thanks for the link, it's entirely possible that something changed since the section was written. However, in my case only the keyboard device has wakeup enabled by default: {{bc|<nowiki><br />
$ for f in /sys/bus/usb/drivers/usb/*/power/wakeup; do echo "$f: $(cat $f)"; done<br />
/sys/bus/usb/drivers/usb/1-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/2-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-11/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-12/power/wakeup: enabled<br />
/sys/bus/usb/drivers/usb/3-13/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-4/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb2/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb4/power/wakeup: disabled<br />
</nowiki>}}<br />
:But in practice it seems to wake up the system even without the host controllers enabled for wakeup... It might also depend on some BIOS/firmware settings but if it works by default on most systems then I think the host controller settings could be removed again.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:14, 19 January 2018 (UTC)<br />
<br />
== Are supported local/remote destinations important for choosing a backup program? ==<br />
<br />
You [[Special:Diff/525550|reverted]] my edit adding supported backup destinations to [[Synchronization_and_backup_programs]]. This is puzzling to me. Here are some thoughts:<br />
* if choosing any backup program, the ability to send the backup off-site vs only on a local disk is a key feature consideration. Perhaps *the* key feature: one helps me recover in case my house gets burglarized or burns down, and the other does not. This is a much more important feature consideration than, say, whether the program is written in Go or Mono (something that has a full column). I think it's hard to disagree on that.<br />
* Given this, I am very puzzled you would use the term "useless" in the revert message.<br />
* I assume you didn't like that the table got even bigger (it didn't fit into the layout even before). I don't like it either, but perhaps the revert should have said "can you put this somewhere else, not in this already-too-big table?"<br />
* On a personal note, when I provide feedback or give opinion on somebody else's work, I'd like to be constructive and kind, instead of aggressive and putting people down. Just a thought. Thanks for listening.<br />
<br />
[[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 17:38, 11 June 2018 (UTC)<br />
<br />
:No because you can use any remote back-end with any backup application by just running one command / writing the backups to a [[FUSE]] (if available).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:39, 12 June 2018 (UTC)<br />
<br />
::Hmm, by that reasoning we don't need the Arch package repository, as long as we have source code and makepkg. Or Perl, if we have bash and awk. But even then, and if all the fuse backends existed (I doubt they do), and if it were easy to set all of them up (another thing I doubt), do you indeed believe that running something written to read/write local files will be just as efficient backing up gigabytes of data to a remote repository as something that is specifically optimized for that use case? Note that backing up, say, daily, a typical hard drive via tpyical consumer broadband is still quite a bandwidth challenge in many places today. What about we add this info, and remove (or merge) some other columns to make the table smaller? {{Unsigned|18:08, 12 June 2018|Jernst}}<br />
<br />
:::Your comparisons don't make sense. Mind the slash in my response, you do not need a FUSE implementation, a simple CLI suffices. You do not need to "set all of them up", you only need one. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 18:47, 12 June 2018 (UTC)<br />
<br />
::::If you ever attempt to help a normal user set up a reliably-working off-site backup strategy, think of this discussion. In the meantime, this is all the time I'm going to spend on a discussion that has such repeated gems in it as "makes no sense" without explaining why you think so. Have a nice day. [[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 18:54, 12 June 2018 (UTC)<br />
<br />
== The pip section in [[Python package guidelines]] ==<br />
<br />
Hi, you wanted the warning about using pip or wheels restored but accidentally(?) reverted my whole set of changes. I redid them, leaving the warning in place. – [[User:Flying sheep|flying sheep]] 08:17, 8 March 2019 (UTC)<br />
<br />
:Full revert was intentional, because the "wheel" section is not a full replacement for "pip" because there are packages which don't provide wheel files. As I said in the edit summary, there is no reason to recommend one or the other due to the warning. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 8 March 2019 (UTC)<br />
::That still doesn’t explain why you reverted the first part, that had nothing to do with the pip/wheel section and simple improves the files.pythonhosted.org URLs. I restored that one while we’re discussing the pip/wheel section. And about that: There’s no reason to use pip for anything else, and pip is only used because some people (me included) didn’t understand that you can install most wheels by just extracting them to the correct location. So what do you think is missing from my wheels section that the former pip section had? – [[User:Flying_sheep|flying sheep]] 11:41, 11 March 2019 (UTC)<br />
<br />
:::If you didn't notice, the page includes "guidelines" in the title. So the page should contain only common and recommended ways to do things, not everything that is possible to do. If you think that your way to install "wheels" should be followed by everybody, feel free to discuss it on the talk page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:26, 11 March 2019 (UTC)<br />
::::Well, extracting static archives sounds much more recommended than running pip with like 7 options to make it behave. I added a talk item: [[Talk:Python package guidelines#Remove_pip_section_in_favor_of_wheels_section?]] – [[User:Flying_sheep|flying sheep]]<br />
<br />
== wpa_supplicant ==<br />
<br />
Regarding https://wiki.archlinux.org/index.php?title=WPA_supplicant&diff=577215&oldid=577167, one person ran into this problem in March of this year and spent too much time diagnosing it:<br />
<br />
https://bbs.archlinux.org/viewtopic.php?id=244950<br />
<br />
It took me a few days to find the problem. I want to make sure the next time someone encounters it, they easily find relevant information about what the cause is. Since you've reverted my edits to both netctl and wpa_supplicant, what do you suggest?<br />
<br />
--<br />
<br />
[[User:Pooryorick|Pooryorick]] ([[User talk:Pooryorick|talk]]) 08:24, 18 July 2019 (UTC)<br />
<br />
== F2FS and GRUB ==<br />
<br />
Hello. :) I'm here to address a recent disagreement. I noticed a reversion of my edit regarding the F2FS filesystem, in particular regarding the configuration file to edit (with you representing /boot/grub/grub.cfg and me representing /etc/default/grub). I run F2FS on my daily driver with an encrypted root filesystem and encrypted boot on a separate partition, and have never had to touch grub.cfg. I only automatically generate it. It's possible to use either, but /etc/default/grub would make more sense as a recommendation in my mind because grub.cfg has the potential to be overwritten during updates, whereas /etc/default/grub doesn't. <br />
<br />
If there's a compelling reason to use grub.cfg over /etc/default/grub, please let me know. ^^ I'm always eager to learn more about Arch. I don't want to get in a reversion war so I've left your change untouched for the time being.<br />
<br />
[[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 00:17, 8 September 2019 (UTC)<br />
<br />
:The reason is explained in the section: "If GRUB is used with an unsupported filesystem it is not able to extract the UUID of your drive so it uses classic non-persistent /dev/sdXx names instead." If it does not apply to F2FS, it should be made clear. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:29, 8 September 2019 (UTC)<br />
<br />
::You can specify UUID's in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, so my proposed solution would work for F2FS and other unsupported filesystems, without the burden of manually editing grub.cfg. If there's anything I need to clarify or something else I'm missing, just let me know. :) [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 19:37, 8 September 2019 (UTC)<br />
<br />
:::The {{ic|1=root=}} parameter is not supposed to be in GRUB_CMDLINE_LINUX_DEFAULT, regardless if UUID is used or not. ''grub-mkconfig'' automatically detects the root filesystem and adds the appropriate {{ic|1=root=}} parameter based on GRUB_DISABLE_LINUX_UUID. In any case, your change to the paragraph does not make sense. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:02, 8 September 2019 (UTC)<br />
<br />
::::It could simply be because I use full disk encryption, and adding a kernel parameter for the encrypted disk's UUID is correct in that situation. You're more experienced with contributing to the wiki, so I guess I'll defer to your judgment. It felt like a reasonable edit and solution to me and I don't see the downside to including it in GRUB_CMDLINE_LINUX_DEFAULT. [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 05:38, 9 September 2019 (UTC)<br />
<br />
== dracut executable link ==<br />
<br />
Hello, your last edit on the dracut page (https://wiki.archlinux.org/index.php?title=Dracut&oldid=596388) that undid my 'Link to direct "make executable" section for executable link' commit states: "the redirect executable points exactly to that section", but it doesn't. Following the [[executable]] link just points to the top of the Help:Reading page.<br />
<br />
{{unsigned|17:06, 28 January 2020|Krathalan}}<br />
<br />
:In that case your browser probably does not work correctly, because the redirect [https://wiki.archlinux.org/index.php?title=Executable&redirect=no really points to the section]. Or MediaWiki, there was a bug several years ago... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 28 January 2020 (UTC)<br />
<br />
:: How strange... thanks for pointing that out. It does indeed appear to be some issue with my Firefox configuration. [[User:Krathalan|Krathalan]] ([[User talk:Krathalan|talk]]) 19:51, 28 January 2020 (UTC)<br />
<br />
== Getting install.php work in DokuWiki ==<br />
<br />
Hi, than you for having undone my contribution and pointed to the right solution on [[Dokuwiki#Configuration]]. Indeed I had read this solution before, but I was misled by the condition "if you are using lighttpd or nginx and your PHP version is lower than 7": as I use Apache with php v. 7.4.3 I didn't take it into account. Do you know what a correct rephrasing could be? Maybe it should be deleted?<br />
<br />
Also, I think that, at the end of this same section, one should add something like "verify that {{Pkg|php-gd}} is installed and restart {{ic|php-fpm.service}}".<br />
<br />
Naturally I can do it myself, but I prefer to ask before.<br />
[[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 17:31, 19 February 2020 (UTC)<br />
<br />
:Hi, apparently it depends on whether you had {{ic|open_basedir}} set previously or not. I've changed the page, feel free to update the gd extension. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:16, 19 February 2020 (UTC)<br />
<br />
::Thank you! However, while, I didn't have {{ic|open_basedir}} set previously, I couldn't access ''install.php''. I suspect there is another thing to do, since the configuration editor in DokuWiki complains that it cannot modify the configuration files although ownership and permissions are correctly set for the relevant symlinks, directories and files, and so is {{ic|open_basedir}}. However I can edit my pages. Maybe a return from a new user with a fresh installation would be more useful, though. [[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 08:20, 20 February 2020 (UTC)<br />
<br />
== Dead link in Simple stateful firewall#See Also ==<br />
<br />
Hi, Jakub. I am about [https://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&diff=599725&oldid=599717 this] edit. I tried to follow that link one more time and it is not require entering captcha. I am not see any content limitations and my colleague (he uses Tor) does not see them too. I am not sure how it works, so I leave it on your descision. -- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 14:29, 1 March 2020 (UTC)<br />
<br />
:Well, maybe it depends on the location from which the request comes. But I don't know how it works either... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:33, 1 March 2020 (UTC)<br />
<br />
::my guess is it returns captcha for crawlers only -- [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 01:59, 2 March 2020 (UTC)<br />
<br />
:::I'm getting it in my browser... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 2 March 2020 (UTC)<br />
<br />
== SystemD user units depending on graphical session ==<br />
Hi,<br />
regarding reverting my addition to [[Systemd/User]], could you please explain why? I referenced [[https://www.freedesktop.org/software/systemd/man/systemd.special.html]] which directly contradicts what you said in your summary.<br />
<br />
{{unsigned|19:53, 5 May 2020|Fuero}}<br />
<br />
:The note in [[Systemd/User#How it works]] still applies - systemd services are never per-session, but per-user. The service does not magically get the correct DISPLAY or WAYLAND_DISPLAY variable, it does not work if you have multiple sessions per user, etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:45, 6 May 2020 (UTC)<br />
<br />
== Plymouth ==<br />
<br />
Actually with just Plymouth it does not work properly. Even 0dd17y had the same issue in https://bbs.archlinux.org/viewtopic.php?id=220900.<br />
<br />
The reason I did not file a bug report is that it is anyway fixed in the git version and the latest release (0.9.4) is around 2 years behind master<br />
<br />
{{unsigned|09:50, 6 May 2020|M.Srikanth}}<br />
<br />
:So if you don't have to file a bug report, add a full troubleshooting entry or at least properly reference your inline note instead of resorting to plain "if that does not work, try this instead". -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:15, 6 May 2020 (UTC)<br />
<br />
== [Bitcoin core] build the code and run the test suites ==<br />
<br />
Hello,<br />
<br />
This week, I managed to build the Bitcoin code and run all the test suites with the help of this page: https://jonatack.github.io/articles/how-to-compile-bitcoin-core-and-run-the-tests<br />
<br />
Archlinux has two particularities:<br />
* being in rolling release, it takes to manually use the library {{ic|Berkeley DB (BDB) v4.8}}<br />
* the {{ic|/tmp}} directory is by default limited to half the size of the Ram<br />
<br />
For these reason, maybe it could be interesting to have a page in the wiki to explain how to build the Bitcoin core?<br />
<br />
Cheers,<br />
<br />
Thomas<br />
<br />
[[User:Thomasb|Thomasb]] ([[User talk:Thomasb|talk]]) 20:29, 9 May 2020 (UTC)<br />
<br />
:I don't think that this is useful. There is the {{AUR|bitcoin-core-git}} package and nothing more should be needed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:53, 26 May 2020 (UTC)<br />
<br />
== Double linefeed results in extra line ==<br />
<br />
If you look at templates that end with double linefeed before noinclude this would result in extra line in resulting page.<br />
<br />
It may be a minor point but since you are perfectionist about wikitext I should mention this is a tradeoff and it results in slightly worse result.<br />
<br />
Removing just one linefeed removes the problem while still allowing it to not jumble all the tags into same line.<br />
<br />
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:30, 11 May 2020 (UTC)<br />
<br />
:If this is about [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=next&oldid=612179], the spaces I added back are not included when the template is used elsewhere, because the spaces are inside the noinclude tags. The extra space is only on the template page itself, but it does not result from template inclusion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:41, 11 May 2020 (UTC)<br />
<br />
::OFC, I mean the template page render has extra line. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 21:21, 11 May 2020 (UTC)<br />
<br />
:::I agree with [[User:Svito|Svito]], isn't it good to delete the extra blank lines? -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 05:39, 12 May 2020 (UTC)<br />
<br />
::::OK, let's do it. [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=616382&oldid=612181] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:47, 26 May 2020 (UTC)<br />
<br />
== Re: lighttpd: remove python2 version ==<br />
<br />
Instead of removing the example we could as well add an example using a Python3 library like https://pypi.org/project/flup6/.<br />
<br />
{{unsigned|15:23, 18 May 2020|Gruentee}}<br />
<br />
:Feel free to add it if you find it useful. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:56, 18 May 2020 (UTC)<br />
<br />
== Xbindkeys removal ==<br />
<br />
Hi, just wondering why you [https://wiki.archlinux.org/index.php?title=Xbindkeys&diff=617675&oldid=617670 removed my edit] from [[Xbindkeys]]? The xbindkeys page has a number of quick tips but no mention of how to bind anything to the Print Screen key so I thought it would be useful to add. -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 02:27, 3 June 2020 (UTC)<br />
<br />
:Giving examples for all keys on the keyboard is useless, there is [[Xbindkeys#Identifying keycodes]] which teaches how to find the keycodes and keysyms of any key. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 3 June 2020 (UTC)<br />
<br />
:: So how come you left the examples for the volume up/down and brightness? What is different between those examples and a screenshot example? Aren't more examples better to save people from hunting all over the place trying to piece things together themselves? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 14:03, 4 June 2020 (UTC)<br />
<br />
:::The difference is that when it comes to volume control, there are 1 or 2 options for the 99% most common cases, but for screenshot taking there are dozens of different options. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:15, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for edit to XDG Base Directory page regarding python_history ==<br />
<br />
I understand the justification for reverting the change I made, however I would like to point out that similar entries on the page (such as Maven) also have instructions for what contents to put in files (even though there is native documentation for those settings). Additionally, it took me a bit of re-reading on the linked Python documentation to reason out how the documentation's example needed to be modified, since it's not clear from the Python documentation whether placing such code in the PYTHONSTARTUP file will actually ''override'' the default behavior. [[User:Varriount|Varriount]] ([[User talk:Varriount|talk]]) 20:44, 20 June 2020 (UTC)<br />
<br />
:Even maven's note can be [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=631704&oldid=631630 shortened]. The notes in the table must be as short as possible, there is no place for extended explanations or long code snippets like in the upstream documentation. If the Python's documentation is not clear enough, I don't think any note in a massive convoluted table will ever be better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:47, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for Backlight page ==<br />
<br />
Hi, you reverted my change to [[Backlight]] page that mentioned WIP patches for controlling OLED panel brightness. I don't really understand justification for reverting it since currently the page says that OLED brightness can be controlled only by changing gamma ramp. That is wrong - since it's not the only way - these panels can control brightness with a PWM. Moreover controlling brightness with gamma ramp is not optimal - it essentially reduces dynamic range, i.e. at 50% you have 7 bits per pixel, at 25% - 6 bit per pixel, etc. That results in banding artifacts at lower brightness level.<br />
<br />
As far waiting for the patches to be merged before mentioning it there - it'll take ~3-6 months (yes, that's the process) and I haven't found *any* reference to these changes on the internet - everyone recommends using gamma ramp instead of fixing it properly. I'm absolutely sure that having information about these patches would not hurt [[User:Anarsoul|Anarsoul]] ([[User talk:Anarsoul|talk]]) 15:56, 30 June 2020 (UTC)<br />
<br />
:Linking to a repo which which has 2 custom commits on top of some arbitrary development version of the Linux kernel tree is not helpful for users. Nobody will compile directly from this repo which is already significantly outdated compared to recent kernel versions and there is no indication if the patches actually work with newer (or older) kernels. We can mention the PWM control as a general concept though. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:32, 12 August 2020 (UTC)<br />
<br />
== Automatic template correction ==<br />
<br />
Per [[Help:Template#Style]], templates should be used with the capitalization shown in the examples in their pages, so {{ic|&#123;{AUR&#124;...}} is correct, while {{ic|&#123;{aur&#124;...}} is not.<br />
<br />
However, there are pages that don't respect that rule (e.g. [[Android_Debug_Bridge]] until recently).<br />
<br />
I beleive this correction should be easy to implement using a bot. What do you think?<br />
<br />
{{unsigned|07:24, 25 August 2020|Relrel}}<br />
<br />
:Yes, this should be easy, but the bot should not make a huge amount of simple style-only changes - they should be combined with corrections for more complex rules. Anyway, there is an idea to create a [https://github.com/lahwaacz/wiki-scripts/issues/22 style linter] for the ArchWiki rules. Would you like to help? ;-) – [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:21, 25 August 2020 (UTC)<br />
<br />
== Failed to create tun device ==<br />
<br />
I don't understand your reason for [[https://wiki.archlinux.org/index.php?title=NetworkManager&diff=0&oldid=634880 removing my section in NetworkManager]]. Could you elaborate?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 07:40, 11 September 2020 (UTC)<br />
<br />
:You can't use [[systemd-networkd]] and [[NetworkManager]] at the same time. Even if you don't have any ''.network'' file for systemd-networkd, you can't solve NetworkManager's problems with systemd-networkd. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:43, 11 September 2020 (UTC)<br />
<br />
::Ok, thanks, in this case it solved the error I got. Now the VPN works. Do you have an idea about how to solve it without systemd-networkd?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 22:27, 11 September 2020 (UTC)<br />
<br />
:::You should really fix the permission problem for {{Pkg|networkmanager-openvpn}}. The tun interface should be managed by OpenVPN which needs rights to create it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 12 September 2020 (UTC)<br />
<br />
::I don't think this statement is entirely correct. [[systemd-networkd]] and [[NetworkManager]] can happily co-exist together if they are managing different interfaces. I unfortunately don't have a reference to point to this, but I came across this being mentioned a couple of times on forums. I personally use [[NetworkManager]] on my laptop to handle wifi, while [[systemd-networkd]] is in control of virtual ethernet and bridges for all my [[systemd-nspawn]] instances. [[User:Romstor|Romstor]] ([[User talk:Romstor|talk]]) 03:24, 12 September 2020 (UTC)<br />
<br />
== [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&oldid=636526/ XDG Base Directory]: Undo revision 636525 ==<br />
<br />
Dear Lahwaacz,<br />
<br />
maybe my changes were to rushed and from my point of view only. But I have two points to consider:<br />
<br />
# If I put the quotes around my vimrc and source it from my .bash_profile, I get the vim-error E471 (Argument required). Without quotes, this doesn't happen. So this change based on experience.<br />
# The rtp should includes directories, which are needed at runtime. (in plain vim e.g. ~/.vim). This is not a typical configuration directory. My mistake was, that I supposed that everyone put their vim plug-ins in $XDG_DATA_HOME and not in $XDG_CONFIG_HOME, because from my point of view a plug-in doesn't belong to the configuration. Maybe it is a good idea to add a remark, which explains the addition of $XDG_CONFIG_HOME to the rtp.<br />
<br />
[[User:Grrr|Grrr]] ([[User talk:Grrr|talk]]) 13:53, 26 September 2020 (UTC)<br />
<br />
# Quotes are there because $XDG_CONFIG_HOME may contain spaces.<br />
# It's not only about quotes - the runtimepath has subdirectories for color schemes, keymaps, autoload scripts etc.<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 26 September 2020 (UTC)<br />
<br />
== Readability in Wiki ==<br />
<br />
I noticed that you and the other admins and moderators often want sentences to continue endlessly, without line breaks.<br />
For example in the introduction of [[Wayland]].<br />
<br />
I think it would be better to have more seperated sentences, so it is easier to read and "important" information is easier visible for people.<br />
I don't know who is responsible, but maybe some options in MediaWiki (or whatever this wiki software is) could be changed as well, to make make line breaks etc. easier and reduce the height-space (if you know what I mean) between sentences, so it looks better, even though line breaks are used.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:38, 15 October 2020 (UTC) G3ro<br />
<br />
:I don't know exactly what you mean. Is it about the readability of the rendered HTML or the "source code" of the page? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:15, 15 October 2020 (UTC)<br />
<br />
:: Well I guess it can be about both. But mainly it is about what people see on the page.<br />
:: There are three seperate topics I mentioned:<br />
<br />
:: 1. Use line breaks: I would like to use more line breaks, because if you have long sentences that are written after each other without line breaks, it gets "harder" to recognize when the next sentence starts.<br />
:: While I agree to what you said somewhere, that sentences that belong directly together, should be written in one "paragraph", it would be useful for sentences that cover (slightly) different "topics" to be visibly parted.<br />
<br />
:: 2. Adjust margin options: I notice that when line breaks are used, there is a vertical space added between two sentences. Just like in this post. If you would use line breaks more often, this is a little too much spacing in my oppinion.<br />
<br />
:: 3. Potential options to make line breaks easier: It would be very convenient if a line break in the source code would lead to a line break in displayed text as well, instead of needing to add an empty line.<br />
<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:33, 15 October 2020 (UTC) G3ro<br />
<br />
:::OK, now I understand. I agree that splitting different topics usually improves legibility, but they should be split into separate paragraphs and not just by line breaks (e.g. using the &lt;br> tags). Paragraphs are semantic units whereas line breaks inside a paragraph are usually typographic errors.<br />
:::Also note that such splitting alone may not be enough to improve the text flow. For example, if we consider the intro for [[Wayland]], the second sentence about XWayland would not constitute a good paragraph - it is just a plain statement and the new topic is not nicely introduced. Ideally, you'd split the topic and make some wording changes for the second paragraph.<br />
:::As for the margin options, that is the difference between paragraph splitting and non-semantic line breaks. In my opinion, the styling is correct in this respect, as paragraphs should be discernible. You mentioned that you like line breaks to easily recognize where a sentence ends - but reading should be based on whole paragraphs, not sentences. There should be no reason to skip anything in the middle of a paragraph, otherwise it should be probably split into multiple paragraphs or otherwise rephrased.<br />
:::If you find it hard to follow a long sentence horizontally on a wide screen, we might consider enforcing some maximum width for the whole content. I think the readability would be better, since there would be more top-to-bottom eye movement at the cost of left-to-right-and-back.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:59, 15 October 2020 (UTC)<br />
<br />
== Xorg parentheses ==<br />
<br />
I actually think that X(org) is very useful to imply that it is one and the same thing.<br />
<br />
It might even be more confusing now, as we use both Xorg and X, because the wiki title and the package titles are Xorg.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:30, 17 October 2020 (UTC) G3ro<br />
<br />
:Well the conventions should be established on the [[Xorg]] page, not anywhere else... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:36, 17 October 2020 (UTC)<br />
<br />
:: Imo the conventions are established by upstream and they use a wide variety of X, X.org, X(org), Xorg etc.<br />
:: As I said I always prefer X(org) because then it is clear, that both are same thing.<br />
:: But ultimately it's your decision. <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:43, 17 October 2020 (UTC) G3ro<br />
<br />
:::When upstream is not capable of making a unambiguous decision, it makes sense that other projects pick some option and stick with it wherever they can to keep at least some consistency. So for this wiki, pages should use the same style as the [[Xorg]] page. But feel free to start a discussion about this in [[Talk:Xorg]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:56, 17 October 2020 (UTC)<br />
<br />
== SSHFS - systemd edit ==<br />
<br />
The edit was removed because "there is no advantage over using fstab entries".<br />
<br />
Is not only about the dis/advantages of the systemd option, is about that it is another possibility to achieve the task, that is why it was created in another level and the fstab section was left alone.<br />
<br />
Reconsider the edit as it presents another option which people can use.<br />
<br />
[[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 16:22, 22 October 2020 (UTC)<br />
<br />
:There is no need to use anything else, fstab just works well enough. Configuring mounts with systemd services is not a good idea - it is much more bloated than fstab and not the right tool for it. If anything, a different type of systemd units should be used: {{man|5|systemd.mount}}. But creating the mount units manually is still pretty useless since everything can be configured in fstab and systemd will generate the unit for you. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:22, 22 October 2020 (UTC)<br />
<br />
:: It is about the ability to use the user's .config file and all the proper options that are saved there. Also systemd gives the possibility to use different targets, so the user could mount it when an specific user logs in or when a graphical session starts. I could argue that bad a modification of fstab could lead to a system that doesnt boot, but such poorly configured systemd unit file just fails and the system is fine. Just give the user the information and let it decide what they can use depending on their use case. [[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 08:08, 24 October 2020 (UTC)<br />
<br />
:::You can configure systemd targets in fstab using the {{ic|x-systemd.wanted-by}} and {{ic|x-systemd.required-by}} options, there are also {{ic|nofail}} and {{ic|noauto}} options. Please read the {{man|5|systemd.mount}} manual.<br />
:::Using hosts from the user's {{ic|.ssh/config}} is the only thing which is not possible with fstab, but this does not warrant using the wrong tool for the task. Simple copy the full {{ic|user@hostname}} into fstab and you're done.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:47, 24 October 2020 (UTC)<br />
<br />
== [[Self-encrypting drives]] ==<br />
<br />
Hi, I'd like to respectfully disagree with the rollback. It's specific to sedutil that with most commands you need to input /dev/nvme0 (when encrypting the device) but for the sleep commands it requires /dev/nvme0n1 or it fails with a very unspecific error (Error saving the password to the kernel errno = 25), as found out in the discussion https://github.com/Drive-Trust-Alliance/sedutil/issues/90<br />
<br />
All in all I believe that it is important to keep this piece of information which was found out in a long discussion between the reporter and the developers. I ran into it and I believe many people may run into it, considering most of the new SSD will be NVMe. Best, [[User:Przemub|Przemub]] ([[User talk:Przemub|talk]]) 13:34, 28 October 2020 (UTC)<br />
<br />
:OK, then it makes sense. But it should be probably explained before, not in the section about the sleep command. Also please add the link to the note as a reference. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:27, 28 October 2020 (UTC)<br />
<br />
== Nvidia Installation ==<br />
<br />
The whole guide is unnecessary long and overcomplicated formulated.<br />
Shorter is better, most people will know their graphic card for example, so the determination etc. is only optional.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:21, 10 November 2020 (UTC) G3ro<br />
<br />
:Moving some info to some other page and leaving a tip behind does not make it shorter, but harder to follow. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:36, 10 November 2020 (UTC)<br />
<br />
== Btrfs layout ==<br />
<br />
Hi, Lahwaacz<br />
<br />
Thanks for maintaining [[Snapper]]! However I think the layout is not openSUSE specific and beneficial to all btrfs users. Can you elaborate your reason of undoing the edits? IMO the previous 'simple layout' complicates the rollback procedure.<br />
<br />
Cheers,<br />
[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 07:26, 3 December 2020 (UTC)<br />
<br />
:It is not overcomplicated, it is just doing things right. You can read about that in the forum thread, see the first note in [[Snapper#Suggested filesystem layout]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:24, 3 December 2020 (UTC)<br />
<br />
::Anyway I've moved the guides to my user page. It's not that I haven't read the 5-year-old forum post, it's that before the current layout I followed that post and resulted in a not fully rolled-back system. That post also sourced (then current) information from openSUSE. openSUSE has since massively overhauled the layout, as I pointed out in an edit you undid earlier.[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 09:02, 3 December 2020 (UTC)<br />
<br />
::Since last message I've extensively documented the new layout at [[User:I2Oc9/Btrfs_subvolumes]] and [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption]]. Have a look for yourself. Nothing new really, but IMO [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my take]] is much more simpler and complete than the supposedly [[Snapper#Restoring_/_to_a_previous_snapshot_of_@|simpler one]]. That one does not leverage native {{ic|snapper rollback}} or {{Pkg|grub-btrfs}}, among other things. I strongly suggest you try if you have time. [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 11:55, 3 December 2020 (UTC)<br />
<br />
::Actually if you look closely, none of [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my recovery methods]] is specific to [[User:I2Oc9/Btrfs_subvolumes#A_new_kind_of_layout|the new 'complex' layout]], it will work totally fine with the old one. I just don't think moving @ around in live environment is appropriate.<br />
<br />
::On the other hand, the layout recommendation has been updated by openSUSE [https://en.opensuse.org/SDB:BTRFS], why stick with the old one? [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 12:37, 3 December 2020 (UTC)<br />
<br />
:::The main reasons why I reverted your edits on the [[Snapper]] page are: 1) it was a huge change which was not discussed previously as required by [[ArchWiki:Contributing#The 3 fundamental rules]], and 2) it has some elements which do not apply to Arch (see below). If you wish to propose a better layout of the subvolumes, it should be discussed in [[Talk:Snapper]] first. Your user pages would serve as great drafts.<br />
:::Note that the current suggested layout is not ''flat'' in the sense of [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|your section]] - it has a separate subvolume for {{ic|.snapshots}} so it does not lead to the recursive mess. So your proposed layout seemed very similar to the current suggested layout. The real difference is which subvolume gets mounted at {{ic|/}}, but I did not find it explained anywhere on the Snapper page before I reverted the changes (I get it now from your user page). I also did not find a proper documentation of the openSUSE's layout - it seems to be just the product of their installer and the documentation only deals with the result, saying at most that [https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-snapper.html#sec-snapper-snapshot-boot the subvolume configuration must not be changed] for rollbacks to work.<br />
:::Now the openSUSE-specific elements: some Arch packages actually install software into {{ic|/opt}}, so the recommended layout should not suggest a separate subvolume for this path. Even more importantly, the pacman database is located at {{ic|/var/lib/pacman/local/}} and it must be rolled back along with the system, so there should be no separate subvolume for {{ic|/var}}. Instead, users should be encouraged to create (even nested) subvolumes for specific data directories under {{ic|/var}}, such as {{ic|/var/log}}, {{ic|/var/tmp}}, {{ic|/var/cache/pacman}}, {{ic|/var/lib/machines}}, etc.<br />
:::Finally, the suggested layout should not be GRUB-specific, there should be no recommendations regarding a boot loader. Sure it is useful to include non-trivial tips, but people may actually use a different boot loader.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:31, 4 December 2020 (UTC)<br />
<br />
::::Thanks for your detailed reply. I admit that I'm not knowledgeable on the intricate differences between distributions and shouldn't have made the changes without properly discussing them first.<br />
::::Yes, I get that the current layout is not [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|the one described in this section]] and indeed properly separates {{ic|/.snapshot}} and {{ic|/}}. The layout I proposed attempts to add some "niceties" such as supporting multi-distribution installations (complex and unnecessary, I agree) and bring the openSUSE layout here, which is a mistake, as you've pointed out.<br />
::::As for GRUB, since I use LUKS all the time and it's the only bootloader supporting encrypted {{ic|/boot}} on Btrfs on LUKS1, I really didn't think of any other possibilities.<br />
::::I will incorporate your recommendations to my user page and add a new section in [[Talk:Snapper]] pointing to those pages.<br />
::::Cheers -- [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:09, 4 December 2020 (UTC)<br />
<br />
:::::I've adopted [[Install_Arch_Linux_on_ZFS#System_datasets|Archlinux Root on ZFS layout]] to [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Create_subvolumes|my proposal]]. [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:56, 4 December 2020 (UTC)<br />
<br />
== Reflector Revert ==<br />
<br />
Hi Lahwaacz, about your [https://wiki.archlinux.org/index.php?title=Reflector&oldid=643749 revert], it seems like there's precedence for including AUR packages that replicate the code on the wiki. For example, in [[dash#Relinking /bin/sh]].<br />
<br />
In addition, I believe that there's value for linking the AUR package because it allows a simpler user experience where the AUR package is maintained for them. That way, if it is ever updated, they can easily fetch the update instead of religiously checking the wiki page (which most users probably don't do).<br />
<br />
Thanks!<br />
<br />
[[User:Denton-l|Denton-l]] ([[User talk:Denton-l|talk]]) 01:52, 7 December 2020 (UTC)<br />
<br />
:That precedence was only created by [https://wiki.archlinux.org/index.php?title=Dash&type=revision&diff=561587&oldid=518398 yourself]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 5 May 2021 (UTC)<br />
<br />
== firefox zoom ==<br />
<br />
"no reason to zoom manually, see HiDPI)" - fractional scaling doesn't work [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 26 December 2020 (UTC)<br />
<br />
:That should be explained in [[HiDPI#Firefox]] anyway. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:48, 26 December 2020 (UTC)<br />
<br />
::it's good to have this mentioned somewhere clearly so people know about it before they say "fonts on linux suck" [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 15:51, 29 December 2020 (UTC)<br />
<br />
== Intel GVT-g edits ==<br />
<br />
Hello Lahwaacz,<br />
<br />
I have noticed that you reverted one of the edits I have performed on [[Intel_GVT-g]].<br />
<br />
About this revert: [https://wiki.archlinux.org/index.php?title=Intel_GVT-g&oldid=648062 Windows problems are out of scope]<br />
<br />
While I understand that the ArchWiki is about ArchLinux, this article in particular mentions Windows in the introduction, and already includes another troubleshooting point about Windows. The issue I have encountered with the black bars is somewhat common, as I have found other people discussing it online, and I really fail to see why not including this piece of information in this article would be better than including it.<br />
<br />
Please, let me know your thoughts. If you think that the point can be improved, I will be happy to do that.<br />
<br />
Ciao,<br />
<br />
[[User:Wilcomir|Wilcomir]] ([[User talk:Wilcomir|talk]]) 09:14, 3 January 2021 (UTC)<br />
<br />
:Well, the existing section about a Windows problem is actually solved by configuring the Linux host. I think anything involving configuration or installation of programs in Windows is not appropriate for long troubleshooting sections. At most, they could be mentioned in a short reference to other sites which describe the problem in detail. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:34, 3 January 2021 (UTC)<br />
<br />
== <s>XDG configuration for Vim</s> ==<br />
<br />
Hi Lahwaacz,<br />
<br />
You have reverted the updated Notes for Vim on [[XDG Base Directory]], because "copy-pasted from a blog post".<br />
<br />
The problem is, not only is the configuration presented currently also copied from a blog post too, but is already 10 years old.<br />
<br />
Would it be OK, if we bring back the more up to date version? Or at least remove the obsolete one and leave link to newer?<br><br />
(Although I think a copy on wiki would be beneficial in case my blog ceases to exist)<br />
<br />
[[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 02:05, 12 January 2021 (UTC)<br />
<br />
:OK let's close this. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:49, 29 August 2021 (UTC)<br />
<br />
== Root on ZFS draft ==<br />
<br />
Hi, I submitted [https://github.com/openzfs/openzfs-docs/pull/104 a Root on ZFS draft] to official doc repo.<br />
<br />
In the draft, the following directories are separated from root filesystem:<br />
home,root,srv,usr/local,var/log,var/spool,var/tmp<br />
<br />
Is this appropriate for Arch Linux? Or do you have any suggestion on the draft?<br />
Any comment is appreciated.<br />
[[User:M0p|M0p]] ([[User talk:M0p|talk]]) 01:28, 23 January 2021 (UTC)<br />
<br />
== Re: undo GRUB - Common installation errors ==<br />
<br />
Concerning your undo of [https://wiki.archlinux.org/index.php?title=GRUB&diff=next&oldid=649799 Add the error message `Could not prepare Boot variable: No space left on device`)]<br />
Is there a better place to for this Information? One can find the solution in various forums, but I thought it could be helpful to have it in this wiki somewhere. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 12:51, 25 January 2021 (UTC)<br />
<br />
:The error message is not specific to the {{ic|/sys/fs/pstore/}} filesystem (which does not even seem to be used by default on Arch...) Where did you find that? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:16, 25 January 2021 (UTC)<br />
<br />
::I did not find anything Arch specific, but this post about Debian helped: [https://donjajo.com/fix-grub-efibootmgr-not-set-variable-no-space-left-device/ Post]. I also found something about [https://askubuntu.com/questions/1072618/could-not-prepare-boot-variable-no-space-left-on-device-grub-install-error-ef /sys/fs/efi/efivars/dump-*] The problem is that the actual efi-partition does not seam to be the problem, there is more than 70% space left. If there is better information to guide the user in the right direction that wuld be more helpful. This is what I found worked, but I admit that I don't know much about how grub operates. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 16:20, 25 January 2021 (UTC)<br />
<br />
:::This wiki ''is'' Arch specific so old posts about Debian or Ubuntu do not apply. Even if they did, this is hardly a ''common'' installation problem. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:29, 26 January 2021 (UTC)<br />
<br />
::::I know that, and would not have put it there if it didn't occur on my Arch Linux installation. If this is something that should not be documented in this wiki, I understand that. Is there any other place you would recommend? An issue for grub-install maybe? [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 22:24, 26 January 2021 (UTC)<br />
<br />
== Kernel Compilation time ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Kernel&diff=next&oldid=650896 link]<br />
<br />
I don't think we should judge information by what is obvious to experts.<br />
People might have experience with compilation of other programs, which mostly is fast, and then there is the kernel which takes forever to compile.<br />
I think it does not hurt anyone to make people aware of it.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:03, 6 February 2021 (UTC)<br />
<br />
:It is an unnecessary information without a definite answer which can even be [https://html.duckduckgo.com/html?q=how%20long%20does%20it%20take%20to%20compile%20Linux%20kernel searched elsewhere]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:23, 6 February 2021 (UTC)<br />
<br />
:: I disagree, with that argument nearly any tip and note is unnecessary. These things are intended to inform users about things that should be taken into consideration and that are different from the norm.<br />
:: Also do you search for the compilation time for every program you intend to compile? I don't.<br />
:: Furthermore this info is included, why not tell it to people directly on the start, so they don't read over it? <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:36, 6 February 2021 (UTC)<br />
<br />
:::If someone wants to compile the Linux kernel, they should obviously expect that it will take ''some time''. Stating that it "can take up to several hours" does not make sense without referring to a specific hardware. Obviously, it will take much longer on a poor laptop than on a powerful workstation with a many-core processor, but people can assume that themselves. Without a reference to a specific hardware, the note is unnecessarily discouraging because the compilation can be as fast as some tens of minutes - it is by far not the most expensive package to compile...<br />
:::As you said, people can find better notes later along with advices to enable parallel build etc. which is all that's needed IMO.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:03, 6 February 2021 (UTC)<br />
<br />
== Wayland style ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Wayland&diff=prev&oldid=650979 link]<br />
<br />
I think in the old version it was much easier to read the "source code", so I don't see why there can't be spaces between it.<br />
Things shouldn't be complicated more than necessary.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:11, 6 February 2021 (UTC)<br />
<br />
:Most templates on the wiki are written without spaces around the |. When we [https://github.com/archlinux/archwiki/pull/32 switch the editor], there will even be syntax highlighting. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:25, 6 February 2021 (UTC)<br />
<br />
== Bluetooth keyboard ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php/Bluetooth_keyboard link]<br />
<br />
On your last change you said "not specific to keyboards, all of this is already mentioned on the Bluetooth page", the point is that this is extremely relevant for bluetooth keyboard since it is required to perform the login! If this little piece cannot be duplicated I would suggest at least to leave a link saying "If you want to autoconnect at boot please refer to...". I'm new here and I would not touch it further, but please evaluate the suggestion (this is because after reading bluetooth keyboard page and not finding the solution I had to look for it on forums)<br />
<br />
{{unsigned|21:17, 20 February 2021|Stevexyz}}<br />
<br />
:Well, basically the whole page is flagged to be merged with the main [[Bluetooth]] page, so it's expected to be incomplete. Other tips may always be found on a more general page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:40, 21 February 2021 (UTC)<br />
<br />
== Re: Steam Needs to be online error ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Steam/Troubleshooting&diff=next&oldid=653073 link]<br />
<br />
The problem here is that DNS resolution in general works already (yes even outside browsers), i.e. <br />
<br />
dig media.steampowered.com<br />
<br />
would run successfully, but the Steam client couldn’t resolve it. The DNS request from 'dig' shows up in my nameserver’s log, the one Steam should send doesn’t. This indicates it might indeed a problem specific to Steam, and it’s not as easy as just say "go fix your DNS resolution", as it already may work correctly for everything but Steam.<br />
<br />
Additionally, at no point does [[Domain name resolution]] even mention nscd, so you effectively removed a fix/workaround for the problem from the Wiki. So I was definitely not "duplicating an article" here. [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 08:12, 22 February 2021 (UTC)<br />
<br />
:Could I please hear your opinion on this? I’d be happy to just add something along the lines of "if you made sure DNS resolution works but Steam still can’t resolve it, try additionally enabling the nscd service" to the Steam troubleshooting page. Unfortounately I don’t know why running the service helps, but I’d still like to give others an easier time finding this solution than I had myself. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 09:15, 28 February 2021 (UTC)<br />
<br />
::Hi, I'm sorry for the delay. Could you test if using a different program for DNS caching (e.g. [[systemd-resolved]]) instead of {{ic|nscd.service}} fixes the problem? If not, then it's probably not due to DNS - {{man|8|nscd}} actually caches more than just DNS. Also if you have a reference to some website where you found about nscd, it would be nice to add it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 28 February 2021 (UTC)<br />
<br />
:::No worries. Using [[systemd-resolved]] for DNS resolution (and caching I guess, I wasn’t aware it does that, too) was a thing I did try, but that didn’t fix it for me. The place I found out about nscd fixing it was actually the [https://bbs.archlinux.org/viewtopic.php?id=263356 Arch forums]. When I search the web for Steam in combination with nscd, all I can seem to find are more forum entries of people that don’t know why that fixes it either. I can try a bit to find out what nscd does to make it work, but I’m not too confident I will be successful. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 14:51, 28 February 2021 (UTC)<br />
<br />
::::Okay, so {{ic|nscd}} allows to [https://man7.org/linux/man-pages/man5/nscd.conf.5.html dis-/enable caching per service], and it’s indeed enabling it for {{ic|hosts}} that makes it work. That’s weird though, since [[systemd-resolved]] has caching enabled by default, and using it for resolution didn’t make {{ic|steam}} work for me. Leads me to think that I didn’t set it up correctly, although resolving via {{ic|dig}} *did* work. Since [[steam]] depends on [[Name Service Switch]], I tried resolving using {{ic|getent}} manually with nscd disabled, but that worked while steam did not. I’m not really sure what to make of this, since I have no idea how this low level networking/resolving stuff works really. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 15:39, 28 February 2021 (UTC)<br />
<br />
:::::Hmm, I don't know the details either. Steam needs the multilib packages so maybe that's part of the problem. Could you add your findings to the section and use [[Template:Expansion]] for the missing details? Maybe someone can figure it out. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:44, 28 February 2021 (UTC)<br />
<br />
::::::Sure, I can do that. I’ll probably need a minute to figure out how to use the template though, but I should have the time later today. Thanks for your input on this. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 17:56, 28 February 2021 (UTC)<br />
<br />
== Removal of website link ==<br />
<br />
Refers to this: https://wiki.archlinux.org/index.php?title=PipeWire&diff=next&oldid=653701<br />
<br />
I don't understand why that has to be removed. The official website should be always worth a mention, even if it is somehow mentioned in the text already.<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:02, 28 February 2021 (UTC)<br />
<br />
:The "See also" section is for additional links, it is not intended as a collection of all links used on a page. Adding links which are clearly mentioned in the appropriate place only clutters the list. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:24, 28 February 2021 (UTC)<br />
<br />
:: There are just three links and only one of them is really useful, the others could maybe even be removed as they link to old blog posts.<br />
:: I can only repeat myself, that things don't always have to be made more complicated than necessary.<br />
:: The official website is a central point which links to many more useful ressources, so it's one link for much information.<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:34, 28 February 2021 (UTC)<br />
<br />
== Removal of bootia32.efi generation procedure from X205TA install page. ==<br />
<br />
Those [https://wiki.archlinux.org/index.php?title=ASUS_x205ta&diff=596239&oldid=562734 instructions] were really straightforward and useful, imho in comparison present ones require too much material to be confident with. I think it's (paradoxically) way easier to generate the file than to configure a `grub.cfg` from zero to boot a live cd. Can we undo the edit? Otherwise we could put them in a new page or section in the GRUB page and link to them maybe. [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 05:07, 4 March 2021 (UTC)<br />
<br />
:If there is something wrong with the information on the [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Booting_64-bit_kernel_on_32-bit_UEFI general page], it should be improved instead of describing the same procedure in a different way on a completely unrelated page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:16, 6 March 2021 (UTC)<br />
<br />
:: I didn't know we had that info in the UEFI article. I think it could be appropriate to insert the [https://en.wikipedia.org/wiki/Template:See_also#Examples See also] archwiki equivalent (which I couldn't find) for UEFI page on top of the aforementioned section, what do you think? [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 13:28, 7 March 2021 (UTC)<br />
<br />
:::Well, the removed section was previously flagged with "Duplicates [[Unified Extensible Firmware Interface#Booting 64-bit kernel on 32-bit UEFI]]"...<br />
:::Also the laptops pages are usually related to most of the general pages on this wiki, adding all of them would be pretty useless. Users should not expect to find everything on a single laptop page, they should always check if there is a general page for their topic with more details.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:58, 7 March 2021 (UTC)<br />
<br />
== Re: Show how to use systemd/Timers with wg-quick@.service ==<br />
<br />
I don't think using service is the appropriate when you want to start Wireguard at boot. For most people connecting to a VPN is not exactly part system startup.<br />
A timer should more appropriate.<br />
[[User:ENV25|ENV25]] ([[User talk:ENV25|talk]]) 10:03, 11 April 2021 (UTC)<br />
<br />
:I don't see how OnBootSec=1min is more appropriate than an automatically starting service. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:19, 11 April 2021 (UTC)<br />
<br />
== USB flash installation medium (BIOS bootable) ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=next&oldid=673926 revert]: "making the partition bootable is discussed below"<br />
Do you mean installing syslinux and `dd` the [gpt]mbr with "discussed below"? This was not enought for my setup (Sandisk Ultra 64GB, Dell XPS 9370) to make the partition BIOS bootable. It did work right after I checked "Legacy BIOS Bootable" checkbox using gnome-disks.<br />
<br />
{{Unsigned|13:42, 30 May 2021 (UTC)|Auipga}}<br />
<br />
:Yes, that's what I meant. If it does not work, it should be fixed rather than providing a duplicate instruction without a reason. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:16, 30 May 2021 (UTC)<br />
<br />
== Systemd-networkd systemd-networkd-wait-online.service discussion modifications ==<br />
<br />
I'm not sure why you're reverting my edits.<br />
<br />
You said: "''empty ExecStart is explained in Systemd#Examples''"<br />
<br />
Exactly: Systemd#Examples clearly states "''As another example, in order to replace the ExecStart directive for a unit that is '''not of type oneshot'''''"<br />
<br />
'''systemd-networkd-wait-online''' is a oneshot service. By having the superfluous empty ExecStart you're just confusing people.<br />
<br />
Regarding the file naming, yes the name is irrelevant, but it's generally helpful to non-expert users to stick to canonical naming conventions.<br />
<br />
Please make sure you're on solid ground before reverting edits; you're just discouraging people from engaging with the Wiki. Thanks. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 16:51, 9 June 2021 (UTC)<br />
<br />
:{{man|5|systemd.service}} says: "Unless Type= is oneshot, exactly one command must be given. When Type=oneshot is used, zero or more commands may be specified."<br />
:So when a service is not oneshot, users ''must'' clear ExecStart before adding a modified command in the drop-in file. If a service is oneshot, they ''may or may not'' clear ExecStart, since the service may have multiple ExecStart commands.<br />
:In case of systemd-networkd-wait-online, I don't see why you would want to run multiple instances with different options: one to wait for ''all'' links (which is the default command) and another one to wait for ''any'' link (which is the command in the drop-in example). So clearing ExecStart really makes sense for systemd-networkd-wait-online.<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:44, 9 June 2021 (UTC)<br />
<br />
== Pacman: Install missing dependencies ==<br />
<br />
Hi. [https://wiki.archlinux.org/index.php?title=Pacman&type=revision&diff=690774&oldid=690762 "Pacman" Revision as of 21:50, 4 August 2021 (undo)] - maybe at least put that into [[System_maintenance#Avoid_certain_pacman_commands]]?<br />
<br />
[[User:Galeksandrp|Galeksandrp]] ([[User talk:Galeksandrp|talk]])<br />
<br />
:[[System_maintenance#Avoid_certain_pacman_commands]] already mentions {{ic|-Rdd}}. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:12, 14 August 2021 (UTC)<br />
<br />
== DPMS: "\033[9;0]" ==<br />
<br />
Hi. It seems that you removed {{ic|echo -ne "\033[9;0]"}} from [[Display Power Management Signaling|DPMS]]<br />
<br />
https://wiki.archlinux.org/index.php?title=Display_Power_Management_Signaling&diff=629705&oldid=625073<br />
<br />
[https://www.denx.de/wiki/view/DULG/SwitchOffScreenSaverAndBlinkingCursor A DULG page] and [https://unix.stackexchange.com/a/23636 a U&L post] brought me here.<br />
<br />
May I ask (1) if this method is still working; and (2) where is this escape sequence documented? [not found in {{man|4|console_codes}}]<br />
<br />
Thanks.<br />
<br />
{{Unsigned|05:23, 15 August 2021 (UTC)|PXf}}<br />
<br />
:[[Display Power Management Signaling#DPMS interaction in a Linux console with setterm]] says that setterm works by writing escape codes to the terminal device. The first subsection shows how to reverse-engineer the escape codes. Note that the escape codes are an implementation detail that users should not be concerned with, their documentation is certainly not our job. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:40, 15 August 2021 (UTC)<br />
<br />
== Linux console/Keyboard configuration ==<br />
<br />
Hi, you recently reverted my edit https://wiki.archlinux.org/index.php?title=Linux_console/Keyboard_configuration&oldid=693887. The reason I made that edit, was that I used to put my custom keymap in {{ic|/usr/local/share/kbd/keymaps/personal}} per the previous version of the wiki page. But this doesn't work with ''sd-vconsole'', as it's include files don't get loaded. Your suggested workaround by adding all required files using [[mkinitcpio#BINARIES and FILES|mkinitcpio BINARIES and FILES]] is rather tedious, as all the include files need to be in there, added by hand. This is done automatically by ''sd-vconsole'' if the file was put in {{ic|/usr/share/kbd/keymaps/}}. The reason I made this edit is due to https://bugs.archlinux.org/task/71788. See Giancarlo Razzolini's comment. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:43, 2 September 2021 (UTC)<br />
<br />
:It's just one custom file under {{ic|/usr/local}} and one entry in {{ic|FILES}}. What is so tedious about it? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:37, 2 September 2021 (UTC)<br />
<br />
:: It's not just one file. All the dependencies need to be included too under {{ic|/usr/share/kbd/keymaps/}}. There are quite a few in my case, when I just include ''us.map'' to modify it slightly. See the ''sd-vconsole'' hook script. That script has a part where it finds all the dependencies of a keymap.<br />
<br />
:: * ''/usr/share/kbd/keymaps/i386/include/compose.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/euro1.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-keys-bare.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-with-alt-and-altgr.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/qwerty-layout.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/personal.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/us.map''<br />
:: * ''/usr/share/kbd/keymaps/include/compose.latin1''<br />
<br />
:: [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 12:01, 2 September 2021 (UTC)<br />
<br />
::: I moved this to the talk page so I remember it and others can discuss too. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:18, 4 September 2021 (UTC)<br />
<br />
::: Oh, I see. In that case I suggest we add a tip like this:<br />
::: {{Tip|If you use the {{ic|sd-vconsole}} [[mkinitcpio#Common hooks|mkinitcpio hook]] instead of {{ic|keymap}}, keymaps located under {{ic|/usr/local}} as well as their dependencies from {{ic|/usr/share/kbd/keymaps}} need to be manually specified in the {{ic|FILES}} array in {{ic|mkinitcpio.conf}}. On the other hand, custom files located in {{ic|/usr/share/kbd/keymaps}} will be added automatically when configured in {{ic|/etc/vconsole.conf}}.}}<br />
::: Because this is relevant only for people using the {{ic|sd-vconsole}} hook and otherwise it does not make sense to pollute {{ic|/usr/share/kbd/keymaps}} with custom files.<br />
::: — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:55, 5 September 2021 (UTC)<br />
<br />
== cow_* ==<br />
<br />
Hi Lahwaacz. About the [https://wiki.archlinux.org/index.php?title=Archiso&diff=next&oldid=692981 how/why issue] (there will be no more &lt;!-- --&gt;). What if, for once, that I want to install some large packages after booting archiso, and would not bother modifying packages.x86_64 and building again? [https://www.memesmonkey.com/topic/works+on+my+machine <s>''on my machine''</s>] Darren "Un1Gfn" "[[User:PXf|PXf]]" Ng ([[User talk:PXf|talk]]) 08:18, 12 October 2021 (UTC)<br />
<br />
:It is a subsection of "Tips and tricks", not "Troubleshooting", so it should start with a clear motivation saying ''why'' the tip is useful, rather than an error message that the user has no idea if they will face or not. If you have such description, feel free to rewrite the section. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 05:42, 13 October 2021 (UTC)<br />
<br />
::What about making it a subsection of "[[Archiso#Troubleshooting|Troubleshooting]]" and renaming it to {{ic|partition / too full}}? [[User:PXf|PXf]] ([[User talk:PXf|talk]]) 06:45, 13 October 2021 (UTC)<br />
<br />
:::It's better to motivate it as a tip/trick rather than solve the problem after it happens. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:48, 13 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
(Undo revision 699881 by Oliver (talk) - installing arch-install-scripts does not get the image to "the same footing" as the archiso, even installing something for the first time is not an excuse to violate Help:Style#Package management instructions)<br />
<br />
'the same footing' may be poor choice of wording maybe but it's also not false. You are in a SIMILAR place, not 'exactly identical to the dot' e.g. same footing<br />
<br />
but 'installing something for the first time' is NOT what is going on here really. If we quote the style guide:<br />
<br />
''every Arch user should know pacman's article by memory''<br />
<br />
<br />
The thing is, this is NOT an Arch user yet. They have no idea what's going on, how to do stuff and just want to get started and installed. You can't expect _new_ not-yet-a user, to figure out everything in a daunting installation; by being a smart-bum about it. Yes, the style guide is completely correct on all other points. But I would think that this is the exception, rather then the rule. Help your new users a little. Introduce them gentle with open arms. From a 'first UX kind of way, this is horrible to treat your potentially new users.<br />
<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 17:40, 26 October 2021 (UTC)<br />
<br />
:We use the same convention on the [[Installation guide]] itself. They should read the [[pacman]] page to learn how to install packages as soon as possible, so why not right when they use it for the first time? There is a gentle link to "[[install]]" before the package name, so the clueless user will follow the link and learn something. They will not learn anything by copy-pasting a quick one-liner. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 26 October 2021 (UTC)<br />
<br />
Yes, you ARE right, however; this is the install guide (relatively speaking) Let them install the system first with a gentle nudge; THEN force them to learn stuff :p<br />
<br />
Again, I understand the policy and the reasoning behind it very much so; but it's those first few steps that are the hardest. It's birds vs humans I suppose; birds throw their children out of their nests to teach them to fly (or die); Humans raise their children first in a more gentle manor. Is arch really the 'l337 fly or die, rtfm n00b' kind of distro?<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 18:25, 26 October 2021 (UTC)<br />
Btw, the big irony is, that I came back on editing this page, as I never finished my first installation when I started that page; and so I had to (again) look-up a lot of stuff, just to be in the 'oh yeah duh' kind of state; so I'm not just offering this suggestions because I think the user needs them, *I* even needed them :) and wanted to help my future self, to one of these days actually make the arch-transition :) (which you are not making any easier :p)<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 18:56, 26 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
skip the rsync protocol<br />
<br />
As per my 'commit message' The user is confronted with the following:<br />
WARNING: failed to rate rsync download (rsync://mirror.erickochen.nl/archlinux/community/os/x86_64/community.db): [Errno 2] No such file or directory: 'rsync'<br />
<br />
You really think we should not reflect this in the documentation for now, until this dependency is actually properly resolved in the package? (could be weeks?)<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 18:32, 26 October 2021 (UTC)<br />
<br />
:Do you get this warning even with the {{ic|--protocol http,https}} that I added in the mentioned change? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:49, 26 October 2021 (UTC)<br />
<br />
Nope, that actually fixes it. I probably got it from an older version of the {{Pkg|reflector}} page which didn't explicitly list it. Btw, is http(s) preferred even over rsync? Is rsync still the 'modern way' to do it?<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 18:54, 26 October 2021 (UTC)</div>Oliverhttps://wiki.archlinux.org/index.php?title=User_talk:Lahwaacz&diff=700025User talk:Lahwaacz2021-10-26T18:54:16Z<p>Oliver: /* Install Arch Linux via Docker */</p>
<hr />
<div>== bot checking links after move ==<br />
<br />
Hi, re [[Talk:Touchpad Synaptics#adding libinput alternative]]. [[Touchpad Synaptics]] has 100+ backlinks and the more important ones - a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of [[Touchpad Synaptics]] and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:36, 26 September 2015 (UTC)<br />
<br />
:Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a [[UUID]] page, which was later generalized and renamed to [[Persistent block device naming]] and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace <nowiki>[[pacman|Install]]</nowiki> with <nowiki>[[Install]]</nowiki> etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:01, 26 September 2015 (UTC)<br />
<br />
::Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [https://wiki.archlinux.org/index.php/Special:WhatLinksHere/Beginners'_Guide]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:02, 26 September 2015 (UTC)<br />
<br />
== mkosi ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=Systemd-nspawn&diff=0&oldid=491975 revert]: You can use mkosi also to create a container/directory tree (-t directory). So it can do the same and more. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 11:33, 1 October 2017 (UTC)<br />
<br />
:Alright, how is the "more" relevant to systemd-nspawn though? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:30, 3 October 2017 (UTC)<br />
<br />
::Hi, mkosi let's you create images (or directory trees) of various different distributions and allows you to do things like setting the root-password or installing additional packages. systemd-nspawn alows you to boot such images/directory trees. So I thought mentioning mkosi as alternative to manually creating a container with pacstrap or debootstrap would be worth it. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 22:23, 5 October 2017 (UTC)<br />
<br />
== Waking from suspend with USB device ==<br />
<br />
Hi Lahwaacz, thanks for your input on this topic.<br />
Can you help me a bit further, I know the USB host controller and the USB device are different things but I thought that enabling the host controller was not necessary anymore, see [https://www.spinics.net/lists/linux-usb/msg53661.html].<br />
In my case all the {{ic|driver/*/power/wakeup}} are all enabled by default and the {{ic|/proc/acpi/wakeup}} as well.<br />
Anyway I have added a step in my explanations to identify the path awaiting for more clarity.<br />
<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 21:57, 16 January 2018 (UTC)<br />
<br />
:Hi, thanks for the link, it's entirely possible that something changed since the section was written. However, in my case only the keyboard device has wakeup enabled by default: {{bc|<nowiki><br />
$ for f in /sys/bus/usb/drivers/usb/*/power/wakeup; do echo "$f: $(cat $f)"; done<br />
/sys/bus/usb/drivers/usb/1-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/2-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-11/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-12/power/wakeup: enabled<br />
/sys/bus/usb/drivers/usb/3-13/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-4/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb2/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb4/power/wakeup: disabled<br />
</nowiki>}}<br />
:But in practice it seems to wake up the system even without the host controllers enabled for wakeup... It might also depend on some BIOS/firmware settings but if it works by default on most systems then I think the host controller settings could be removed again.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:14, 19 January 2018 (UTC)<br />
<br />
== Are supported local/remote destinations important for choosing a backup program? ==<br />
<br />
You [[Special:Diff/525550|reverted]] my edit adding supported backup destinations to [[Synchronization_and_backup_programs]]. This is puzzling to me. Here are some thoughts:<br />
* if choosing any backup program, the ability to send the backup off-site vs only on a local disk is a key feature consideration. Perhaps *the* key feature: one helps me recover in case my house gets burglarized or burns down, and the other does not. This is a much more important feature consideration than, say, whether the program is written in Go or Mono (something that has a full column). I think it's hard to disagree on that.<br />
* Given this, I am very puzzled you would use the term "useless" in the revert message.<br />
* I assume you didn't like that the table got even bigger (it didn't fit into the layout even before). I don't like it either, but perhaps the revert should have said "can you put this somewhere else, not in this already-too-big table?"<br />
* On a personal note, when I provide feedback or give opinion on somebody else's work, I'd like to be constructive and kind, instead of aggressive and putting people down. Just a thought. Thanks for listening.<br />
<br />
[[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 17:38, 11 June 2018 (UTC)<br />
<br />
:No because you can use any remote back-end with any backup application by just running one command / writing the backups to a [[FUSE]] (if available).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:39, 12 June 2018 (UTC)<br />
<br />
::Hmm, by that reasoning we don't need the Arch package repository, as long as we have source code and makepkg. Or Perl, if we have bash and awk. But even then, and if all the fuse backends existed (I doubt they do), and if it were easy to set all of them up (another thing I doubt), do you indeed believe that running something written to read/write local files will be just as efficient backing up gigabytes of data to a remote repository as something that is specifically optimized for that use case? Note that backing up, say, daily, a typical hard drive via tpyical consumer broadband is still quite a bandwidth challenge in many places today. What about we add this info, and remove (or merge) some other columns to make the table smaller? {{Unsigned|18:08, 12 June 2018|Jernst}}<br />
<br />
:::Your comparisons don't make sense. Mind the slash in my response, you do not need a FUSE implementation, a simple CLI suffices. You do not need to "set all of them up", you only need one. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 18:47, 12 June 2018 (UTC)<br />
<br />
::::If you ever attempt to help a normal user set up a reliably-working off-site backup strategy, think of this discussion. In the meantime, this is all the time I'm going to spend on a discussion that has such repeated gems in it as "makes no sense" without explaining why you think so. Have a nice day. [[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 18:54, 12 June 2018 (UTC)<br />
<br />
== The pip section in [[Python package guidelines]] ==<br />
<br />
Hi, you wanted the warning about using pip or wheels restored but accidentally(?) reverted my whole set of changes. I redid them, leaving the warning in place. – [[User:Flying sheep|flying sheep]] 08:17, 8 March 2019 (UTC)<br />
<br />
:Full revert was intentional, because the "wheel" section is not a full replacement for "pip" because there are packages which don't provide wheel files. As I said in the edit summary, there is no reason to recommend one or the other due to the warning. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 8 March 2019 (UTC)<br />
::That still doesn’t explain why you reverted the first part, that had nothing to do with the pip/wheel section and simple improves the files.pythonhosted.org URLs. I restored that one while we’re discussing the pip/wheel section. And about that: There’s no reason to use pip for anything else, and pip is only used because some people (me included) didn’t understand that you can install most wheels by just extracting them to the correct location. So what do you think is missing from my wheels section that the former pip section had? – [[User:Flying_sheep|flying sheep]] 11:41, 11 March 2019 (UTC)<br />
<br />
:::If you didn't notice, the page includes "guidelines" in the title. So the page should contain only common and recommended ways to do things, not everything that is possible to do. If you think that your way to install "wheels" should be followed by everybody, feel free to discuss it on the talk page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:26, 11 March 2019 (UTC)<br />
::::Well, extracting static archives sounds much more recommended than running pip with like 7 options to make it behave. I added a talk item: [[Talk:Python package guidelines#Remove_pip_section_in_favor_of_wheels_section?]] – [[User:Flying_sheep|flying sheep]]<br />
<br />
== wpa_supplicant ==<br />
<br />
Regarding https://wiki.archlinux.org/index.php?title=WPA_supplicant&diff=577215&oldid=577167, one person ran into this problem in March of this year and spent too much time diagnosing it:<br />
<br />
https://bbs.archlinux.org/viewtopic.php?id=244950<br />
<br />
It took me a few days to find the problem. I want to make sure the next time someone encounters it, they easily find relevant information about what the cause is. Since you've reverted my edits to both netctl and wpa_supplicant, what do you suggest?<br />
<br />
--<br />
<br />
[[User:Pooryorick|Pooryorick]] ([[User talk:Pooryorick|talk]]) 08:24, 18 July 2019 (UTC)<br />
<br />
== F2FS and GRUB ==<br />
<br />
Hello. :) I'm here to address a recent disagreement. I noticed a reversion of my edit regarding the F2FS filesystem, in particular regarding the configuration file to edit (with you representing /boot/grub/grub.cfg and me representing /etc/default/grub). I run F2FS on my daily driver with an encrypted root filesystem and encrypted boot on a separate partition, and have never had to touch grub.cfg. I only automatically generate it. It's possible to use either, but /etc/default/grub would make more sense as a recommendation in my mind because grub.cfg has the potential to be overwritten during updates, whereas /etc/default/grub doesn't. <br />
<br />
If there's a compelling reason to use grub.cfg over /etc/default/grub, please let me know. ^^ I'm always eager to learn more about Arch. I don't want to get in a reversion war so I've left your change untouched for the time being.<br />
<br />
[[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 00:17, 8 September 2019 (UTC)<br />
<br />
:The reason is explained in the section: "If GRUB is used with an unsupported filesystem it is not able to extract the UUID of your drive so it uses classic non-persistent /dev/sdXx names instead." If it does not apply to F2FS, it should be made clear. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:29, 8 September 2019 (UTC)<br />
<br />
::You can specify UUID's in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, so my proposed solution would work for F2FS and other unsupported filesystems, without the burden of manually editing grub.cfg. If there's anything I need to clarify or something else I'm missing, just let me know. :) [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 19:37, 8 September 2019 (UTC)<br />
<br />
:::The {{ic|1=root=}} parameter is not supposed to be in GRUB_CMDLINE_LINUX_DEFAULT, regardless if UUID is used or not. ''grub-mkconfig'' automatically detects the root filesystem and adds the appropriate {{ic|1=root=}} parameter based on GRUB_DISABLE_LINUX_UUID. In any case, your change to the paragraph does not make sense. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:02, 8 September 2019 (UTC)<br />
<br />
::::It could simply be because I use full disk encryption, and adding a kernel parameter for the encrypted disk's UUID is correct in that situation. You're more experienced with contributing to the wiki, so I guess I'll defer to your judgment. It felt like a reasonable edit and solution to me and I don't see the downside to including it in GRUB_CMDLINE_LINUX_DEFAULT. [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 05:38, 9 September 2019 (UTC)<br />
<br />
== dracut executable link ==<br />
<br />
Hello, your last edit on the dracut page (https://wiki.archlinux.org/index.php?title=Dracut&oldid=596388) that undid my 'Link to direct "make executable" section for executable link' commit states: "the redirect executable points exactly to that section", but it doesn't. Following the [[executable]] link just points to the top of the Help:Reading page.<br />
<br />
{{unsigned|17:06, 28 January 2020|Krathalan}}<br />
<br />
:In that case your browser probably does not work correctly, because the redirect [https://wiki.archlinux.org/index.php?title=Executable&redirect=no really points to the section]. Or MediaWiki, there was a bug several years ago... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 28 January 2020 (UTC)<br />
<br />
:: How strange... thanks for pointing that out. It does indeed appear to be some issue with my Firefox configuration. [[User:Krathalan|Krathalan]] ([[User talk:Krathalan|talk]]) 19:51, 28 January 2020 (UTC)<br />
<br />
== Getting install.php work in DokuWiki ==<br />
<br />
Hi, than you for having undone my contribution and pointed to the right solution on [[Dokuwiki#Configuration]]. Indeed I had read this solution before, but I was misled by the condition "if you are using lighttpd or nginx and your PHP version is lower than 7": as I use Apache with php v. 7.4.3 I didn't take it into account. Do you know what a correct rephrasing could be? Maybe it should be deleted?<br />
<br />
Also, I think that, at the end of this same section, one should add something like "verify that {{Pkg|php-gd}} is installed and restart {{ic|php-fpm.service}}".<br />
<br />
Naturally I can do it myself, but I prefer to ask before.<br />
[[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 17:31, 19 February 2020 (UTC)<br />
<br />
:Hi, apparently it depends on whether you had {{ic|open_basedir}} set previously or not. I've changed the page, feel free to update the gd extension. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:16, 19 February 2020 (UTC)<br />
<br />
::Thank you! However, while, I didn't have {{ic|open_basedir}} set previously, I couldn't access ''install.php''. I suspect there is another thing to do, since the configuration editor in DokuWiki complains that it cannot modify the configuration files although ownership and permissions are correctly set for the relevant symlinks, directories and files, and so is {{ic|open_basedir}}. However I can edit my pages. Maybe a return from a new user with a fresh installation would be more useful, though. [[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 08:20, 20 February 2020 (UTC)<br />
<br />
== Dead link in Simple stateful firewall#See Also ==<br />
<br />
Hi, Jakub. I am about [https://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&diff=599725&oldid=599717 this] edit. I tried to follow that link one more time and it is not require entering captcha. I am not see any content limitations and my colleague (he uses Tor) does not see them too. I am not sure how it works, so I leave it on your descision. -- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 14:29, 1 March 2020 (UTC)<br />
<br />
:Well, maybe it depends on the location from which the request comes. But I don't know how it works either... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:33, 1 March 2020 (UTC)<br />
<br />
::my guess is it returns captcha for crawlers only -- [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 01:59, 2 March 2020 (UTC)<br />
<br />
:::I'm getting it in my browser... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 2 March 2020 (UTC)<br />
<br />
== SystemD user units depending on graphical session ==<br />
Hi,<br />
regarding reverting my addition to [[Systemd/User]], could you please explain why? I referenced [[https://www.freedesktop.org/software/systemd/man/systemd.special.html]] which directly contradicts what you said in your summary.<br />
<br />
{{unsigned|19:53, 5 May 2020|Fuero}}<br />
<br />
:The note in [[Systemd/User#How it works]] still applies - systemd services are never per-session, but per-user. The service does not magically get the correct DISPLAY or WAYLAND_DISPLAY variable, it does not work if you have multiple sessions per user, etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:45, 6 May 2020 (UTC)<br />
<br />
== Plymouth ==<br />
<br />
Actually with just Plymouth it does not work properly. Even 0dd17y had the same issue in https://bbs.archlinux.org/viewtopic.php?id=220900.<br />
<br />
The reason I did not file a bug report is that it is anyway fixed in the git version and the latest release (0.9.4) is around 2 years behind master<br />
<br />
{{unsigned|09:50, 6 May 2020|M.Srikanth}}<br />
<br />
:So if you don't have to file a bug report, add a full troubleshooting entry or at least properly reference your inline note instead of resorting to plain "if that does not work, try this instead". -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:15, 6 May 2020 (UTC)<br />
<br />
== [Bitcoin core] build the code and run the test suites ==<br />
<br />
Hello,<br />
<br />
This week, I managed to build the Bitcoin code and run all the test suites with the help of this page: https://jonatack.github.io/articles/how-to-compile-bitcoin-core-and-run-the-tests<br />
<br />
Archlinux has two particularities:<br />
* being in rolling release, it takes to manually use the library {{ic|Berkeley DB (BDB) v4.8}}<br />
* the {{ic|/tmp}} directory is by default limited to half the size of the Ram<br />
<br />
For these reason, maybe it could be interesting to have a page in the wiki to explain how to build the Bitcoin core?<br />
<br />
Cheers,<br />
<br />
Thomas<br />
<br />
[[User:Thomasb|Thomasb]] ([[User talk:Thomasb|talk]]) 20:29, 9 May 2020 (UTC)<br />
<br />
:I don't think that this is useful. There is the {{AUR|bitcoin-core-git}} package and nothing more should be needed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:53, 26 May 2020 (UTC)<br />
<br />
== Double linefeed results in extra line ==<br />
<br />
If you look at templates that end with double linefeed before noinclude this would result in extra line in resulting page.<br />
<br />
It may be a minor point but since you are perfectionist about wikitext I should mention this is a tradeoff and it results in slightly worse result.<br />
<br />
Removing just one linefeed removes the problem while still allowing it to not jumble all the tags into same line.<br />
<br />
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:30, 11 May 2020 (UTC)<br />
<br />
:If this is about [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=next&oldid=612179], the spaces I added back are not included when the template is used elsewhere, because the spaces are inside the noinclude tags. The extra space is only on the template page itself, but it does not result from template inclusion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:41, 11 May 2020 (UTC)<br />
<br />
::OFC, I mean the template page render has extra line. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 21:21, 11 May 2020 (UTC)<br />
<br />
:::I agree with [[User:Svito|Svito]], isn't it good to delete the extra blank lines? -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 05:39, 12 May 2020 (UTC)<br />
<br />
::::OK, let's do it. [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=616382&oldid=612181] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:47, 26 May 2020 (UTC)<br />
<br />
== Re: lighttpd: remove python2 version ==<br />
<br />
Instead of removing the example we could as well add an example using a Python3 library like https://pypi.org/project/flup6/.<br />
<br />
{{unsigned|15:23, 18 May 2020|Gruentee}}<br />
<br />
:Feel free to add it if you find it useful. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:56, 18 May 2020 (UTC)<br />
<br />
== Xbindkeys removal ==<br />
<br />
Hi, just wondering why you [https://wiki.archlinux.org/index.php?title=Xbindkeys&diff=617675&oldid=617670 removed my edit] from [[Xbindkeys]]? The xbindkeys page has a number of quick tips but no mention of how to bind anything to the Print Screen key so I thought it would be useful to add. -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 02:27, 3 June 2020 (UTC)<br />
<br />
:Giving examples for all keys on the keyboard is useless, there is [[Xbindkeys#Identifying keycodes]] which teaches how to find the keycodes and keysyms of any key. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 3 June 2020 (UTC)<br />
<br />
:: So how come you left the examples for the volume up/down and brightness? What is different between those examples and a screenshot example? Aren't more examples better to save people from hunting all over the place trying to piece things together themselves? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 14:03, 4 June 2020 (UTC)<br />
<br />
:::The difference is that when it comes to volume control, there are 1 or 2 options for the 99% most common cases, but for screenshot taking there are dozens of different options. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:15, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for edit to XDG Base Directory page regarding python_history ==<br />
<br />
I understand the justification for reverting the change I made, however I would like to point out that similar entries on the page (such as Maven) also have instructions for what contents to put in files (even though there is native documentation for those settings). Additionally, it took me a bit of re-reading on the linked Python documentation to reason out how the documentation's example needed to be modified, since it's not clear from the Python documentation whether placing such code in the PYTHONSTARTUP file will actually ''override'' the default behavior. [[User:Varriount|Varriount]] ([[User talk:Varriount|talk]]) 20:44, 20 June 2020 (UTC)<br />
<br />
:Even maven's note can be [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=631704&oldid=631630 shortened]. The notes in the table must be as short as possible, there is no place for extended explanations or long code snippets like in the upstream documentation. If the Python's documentation is not clear enough, I don't think any note in a massive convoluted table will ever be better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:47, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for Backlight page ==<br />
<br />
Hi, you reverted my change to [[Backlight]] page that mentioned WIP patches for controlling OLED panel brightness. I don't really understand justification for reverting it since currently the page says that OLED brightness can be controlled only by changing gamma ramp. That is wrong - since it's not the only way - these panels can control brightness with a PWM. Moreover controlling brightness with gamma ramp is not optimal - it essentially reduces dynamic range, i.e. at 50% you have 7 bits per pixel, at 25% - 6 bit per pixel, etc. That results in banding artifacts at lower brightness level.<br />
<br />
As far waiting for the patches to be merged before mentioning it there - it'll take ~3-6 months (yes, that's the process) and I haven't found *any* reference to these changes on the internet - everyone recommends using gamma ramp instead of fixing it properly. I'm absolutely sure that having information about these patches would not hurt [[User:Anarsoul|Anarsoul]] ([[User talk:Anarsoul|talk]]) 15:56, 30 June 2020 (UTC)<br />
<br />
:Linking to a repo which which has 2 custom commits on top of some arbitrary development version of the Linux kernel tree is not helpful for users. Nobody will compile directly from this repo which is already significantly outdated compared to recent kernel versions and there is no indication if the patches actually work with newer (or older) kernels. We can mention the PWM control as a general concept though. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:32, 12 August 2020 (UTC)<br />
<br />
== Automatic template correction ==<br />
<br />
Per [[Help:Template#Style]], templates should be used with the capitalization shown in the examples in their pages, so {{ic|&#123;{AUR&#124;...}} is correct, while {{ic|&#123;{aur&#124;...}} is not.<br />
<br />
However, there are pages that don't respect that rule (e.g. [[Android_Debug_Bridge]] until recently).<br />
<br />
I beleive this correction should be easy to implement using a bot. What do you think?<br />
<br />
{{unsigned|07:24, 25 August 2020|Relrel}}<br />
<br />
:Yes, this should be easy, but the bot should not make a huge amount of simple style-only changes - they should be combined with corrections for more complex rules. Anyway, there is an idea to create a [https://github.com/lahwaacz/wiki-scripts/issues/22 style linter] for the ArchWiki rules. Would you like to help? ;-) – [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:21, 25 August 2020 (UTC)<br />
<br />
== Failed to create tun device ==<br />
<br />
I don't understand your reason for [[https://wiki.archlinux.org/index.php?title=NetworkManager&diff=0&oldid=634880 removing my section in NetworkManager]]. Could you elaborate?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 07:40, 11 September 2020 (UTC)<br />
<br />
:You can't use [[systemd-networkd]] and [[NetworkManager]] at the same time. Even if you don't have any ''.network'' file for systemd-networkd, you can't solve NetworkManager's problems with systemd-networkd. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:43, 11 September 2020 (UTC)<br />
<br />
::Ok, thanks, in this case it solved the error I got. Now the VPN works. Do you have an idea about how to solve it without systemd-networkd?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 22:27, 11 September 2020 (UTC)<br />
<br />
:::You should really fix the permission problem for {{Pkg|networkmanager-openvpn}}. The tun interface should be managed by OpenVPN which needs rights to create it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 12 September 2020 (UTC)<br />
<br />
::I don't think this statement is entirely correct. [[systemd-networkd]] and [[NetworkManager]] can happily co-exist together if they are managing different interfaces. I unfortunately don't have a reference to point to this, but I came across this being mentioned a couple of times on forums. I personally use [[NetworkManager]] on my laptop to handle wifi, while [[systemd-networkd]] is in control of virtual ethernet and bridges for all my [[systemd-nspawn]] instances. [[User:Romstor|Romstor]] ([[User talk:Romstor|talk]]) 03:24, 12 September 2020 (UTC)<br />
<br />
== [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&oldid=636526/ XDG Base Directory]: Undo revision 636525 ==<br />
<br />
Dear Lahwaacz,<br />
<br />
maybe my changes were to rushed and from my point of view only. But I have two points to consider:<br />
<br />
# If I put the quotes around my vimrc and source it from my .bash_profile, I get the vim-error E471 (Argument required). Without quotes, this doesn't happen. So this change based on experience.<br />
# The rtp should includes directories, which are needed at runtime. (in plain vim e.g. ~/.vim). This is not a typical configuration directory. My mistake was, that I supposed that everyone put their vim plug-ins in $XDG_DATA_HOME and not in $XDG_CONFIG_HOME, because from my point of view a plug-in doesn't belong to the configuration. Maybe it is a good idea to add a remark, which explains the addition of $XDG_CONFIG_HOME to the rtp.<br />
<br />
[[User:Grrr|Grrr]] ([[User talk:Grrr|talk]]) 13:53, 26 September 2020 (UTC)<br />
<br />
# Quotes are there because $XDG_CONFIG_HOME may contain spaces.<br />
# It's not only about quotes - the runtimepath has subdirectories for color schemes, keymaps, autoload scripts etc.<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 26 September 2020 (UTC)<br />
<br />
== Readability in Wiki ==<br />
<br />
I noticed that you and the other admins and moderators often want sentences to continue endlessly, without line breaks.<br />
For example in the introduction of [[Wayland]].<br />
<br />
I think it would be better to have more seperated sentences, so it is easier to read and "important" information is easier visible for people.<br />
I don't know who is responsible, but maybe some options in MediaWiki (or whatever this wiki software is) could be changed as well, to make make line breaks etc. easier and reduce the height-space (if you know what I mean) between sentences, so it looks better, even though line breaks are used.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:38, 15 October 2020 (UTC) G3ro<br />
<br />
:I don't know exactly what you mean. Is it about the readability of the rendered HTML or the "source code" of the page? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:15, 15 October 2020 (UTC)<br />
<br />
:: Well I guess it can be about both. But mainly it is about what people see on the page.<br />
:: There are three seperate topics I mentioned:<br />
<br />
:: 1. Use line breaks: I would like to use more line breaks, because if you have long sentences that are written after each other without line breaks, it gets "harder" to recognize when the next sentence starts.<br />
:: While I agree to what you said somewhere, that sentences that belong directly together, should be written in one "paragraph", it would be useful for sentences that cover (slightly) different "topics" to be visibly parted.<br />
<br />
:: 2. Adjust margin options: I notice that when line breaks are used, there is a vertical space added between two sentences. Just like in this post. If you would use line breaks more often, this is a little too much spacing in my oppinion.<br />
<br />
:: 3. Potential options to make line breaks easier: It would be very convenient if a line break in the source code would lead to a line break in displayed text as well, instead of needing to add an empty line.<br />
<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:33, 15 October 2020 (UTC) G3ro<br />
<br />
:::OK, now I understand. I agree that splitting different topics usually improves legibility, but they should be split into separate paragraphs and not just by line breaks (e.g. using the &lt;br> tags). Paragraphs are semantic units whereas line breaks inside a paragraph are usually typographic errors.<br />
:::Also note that such splitting alone may not be enough to improve the text flow. For example, if we consider the intro for [[Wayland]], the second sentence about XWayland would not constitute a good paragraph - it is just a plain statement and the new topic is not nicely introduced. Ideally, you'd split the topic and make some wording changes for the second paragraph.<br />
:::As for the margin options, that is the difference between paragraph splitting and non-semantic line breaks. In my opinion, the styling is correct in this respect, as paragraphs should be discernible. You mentioned that you like line breaks to easily recognize where a sentence ends - but reading should be based on whole paragraphs, not sentences. There should be no reason to skip anything in the middle of a paragraph, otherwise it should be probably split into multiple paragraphs or otherwise rephrased.<br />
:::If you find it hard to follow a long sentence horizontally on a wide screen, we might consider enforcing some maximum width for the whole content. I think the readability would be better, since there would be more top-to-bottom eye movement at the cost of left-to-right-and-back.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:59, 15 October 2020 (UTC)<br />
<br />
== Xorg parentheses ==<br />
<br />
I actually think that X(org) is very useful to imply that it is one and the same thing.<br />
<br />
It might even be more confusing now, as we use both Xorg and X, because the wiki title and the package titles are Xorg.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:30, 17 October 2020 (UTC) G3ro<br />
<br />
:Well the conventions should be established on the [[Xorg]] page, not anywhere else... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:36, 17 October 2020 (UTC)<br />
<br />
:: Imo the conventions are established by upstream and they use a wide variety of X, X.org, X(org), Xorg etc.<br />
:: As I said I always prefer X(org) because then it is clear, that both are same thing.<br />
:: But ultimately it's your decision. <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:43, 17 October 2020 (UTC) G3ro<br />
<br />
:::When upstream is not capable of making a unambiguous decision, it makes sense that other projects pick some option and stick with it wherever they can to keep at least some consistency. So for this wiki, pages should use the same style as the [[Xorg]] page. But feel free to start a discussion about this in [[Talk:Xorg]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:56, 17 October 2020 (UTC)<br />
<br />
== SSHFS - systemd edit ==<br />
<br />
The edit was removed because "there is no advantage over using fstab entries".<br />
<br />
Is not only about the dis/advantages of the systemd option, is about that it is another possibility to achieve the task, that is why it was created in another level and the fstab section was left alone.<br />
<br />
Reconsider the edit as it presents another option which people can use.<br />
<br />
[[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 16:22, 22 October 2020 (UTC)<br />
<br />
:There is no need to use anything else, fstab just works well enough. Configuring mounts with systemd services is not a good idea - it is much more bloated than fstab and not the right tool for it. If anything, a different type of systemd units should be used: {{man|5|systemd.mount}}. But creating the mount units manually is still pretty useless since everything can be configured in fstab and systemd will generate the unit for you. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:22, 22 October 2020 (UTC)<br />
<br />
:: It is about the ability to use the user's .config file and all the proper options that are saved there. Also systemd gives the possibility to use different targets, so the user could mount it when an specific user logs in or when a graphical session starts. I could argue that bad a modification of fstab could lead to a system that doesnt boot, but such poorly configured systemd unit file just fails and the system is fine. Just give the user the information and let it decide what they can use depending on their use case. [[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 08:08, 24 October 2020 (UTC)<br />
<br />
:::You can configure systemd targets in fstab using the {{ic|x-systemd.wanted-by}} and {{ic|x-systemd.required-by}} options, there are also {{ic|nofail}} and {{ic|noauto}} options. Please read the {{man|5|systemd.mount}} manual.<br />
:::Using hosts from the user's {{ic|.ssh/config}} is the only thing which is not possible with fstab, but this does not warrant using the wrong tool for the task. Simple copy the full {{ic|user@hostname}} into fstab and you're done.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:47, 24 October 2020 (UTC)<br />
<br />
== [[Self-encrypting drives]] ==<br />
<br />
Hi, I'd like to respectfully disagree with the rollback. It's specific to sedutil that with most commands you need to input /dev/nvme0 (when encrypting the device) but for the sleep commands it requires /dev/nvme0n1 or it fails with a very unspecific error (Error saving the password to the kernel errno = 25), as found out in the discussion https://github.com/Drive-Trust-Alliance/sedutil/issues/90<br />
<br />
All in all I believe that it is important to keep this piece of information which was found out in a long discussion between the reporter and the developers. I ran into it and I believe many people may run into it, considering most of the new SSD will be NVMe. Best, [[User:Przemub|Przemub]] ([[User talk:Przemub|talk]]) 13:34, 28 October 2020 (UTC)<br />
<br />
:OK, then it makes sense. But it should be probably explained before, not in the section about the sleep command. Also please add the link to the note as a reference. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:27, 28 October 2020 (UTC)<br />
<br />
== Nvidia Installation ==<br />
<br />
The whole guide is unnecessary long and overcomplicated formulated.<br />
Shorter is better, most people will know their graphic card for example, so the determination etc. is only optional.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:21, 10 November 2020 (UTC) G3ro<br />
<br />
:Moving some info to some other page and leaving a tip behind does not make it shorter, but harder to follow. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:36, 10 November 2020 (UTC)<br />
<br />
== Btrfs layout ==<br />
<br />
Hi, Lahwaacz<br />
<br />
Thanks for maintaining [[Snapper]]! However I think the layout is not openSUSE specific and beneficial to all btrfs users. Can you elaborate your reason of undoing the edits? IMO the previous 'simple layout' complicates the rollback procedure.<br />
<br />
Cheers,<br />
[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 07:26, 3 December 2020 (UTC)<br />
<br />
:It is not overcomplicated, it is just doing things right. You can read about that in the forum thread, see the first note in [[Snapper#Suggested filesystem layout]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:24, 3 December 2020 (UTC)<br />
<br />
::Anyway I've moved the guides to my user page. It's not that I haven't read the 5-year-old forum post, it's that before the current layout I followed that post and resulted in a not fully rolled-back system. That post also sourced (then current) information from openSUSE. openSUSE has since massively overhauled the layout, as I pointed out in an edit you undid earlier.[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 09:02, 3 December 2020 (UTC)<br />
<br />
::Since last message I've extensively documented the new layout at [[User:I2Oc9/Btrfs_subvolumes]] and [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption]]. Have a look for yourself. Nothing new really, but IMO [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my take]] is much more simpler and complete than the supposedly [[Snapper#Restoring_/_to_a_previous_snapshot_of_@|simpler one]]. That one does not leverage native {{ic|snapper rollback}} or {{Pkg|grub-btrfs}}, among other things. I strongly suggest you try if you have time. [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 11:55, 3 December 2020 (UTC)<br />
<br />
::Actually if you look closely, none of [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my recovery methods]] is specific to [[User:I2Oc9/Btrfs_subvolumes#A_new_kind_of_layout|the new 'complex' layout]], it will work totally fine with the old one. I just don't think moving @ around in live environment is appropriate.<br />
<br />
::On the other hand, the layout recommendation has been updated by openSUSE [https://en.opensuse.org/SDB:BTRFS], why stick with the old one? [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 12:37, 3 December 2020 (UTC)<br />
<br />
:::The main reasons why I reverted your edits on the [[Snapper]] page are: 1) it was a huge change which was not discussed previously as required by [[ArchWiki:Contributing#The 3 fundamental rules]], and 2) it has some elements which do not apply to Arch (see below). If you wish to propose a better layout of the subvolumes, it should be discussed in [[Talk:Snapper]] first. Your user pages would serve as great drafts.<br />
:::Note that the current suggested layout is not ''flat'' in the sense of [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|your section]] - it has a separate subvolume for {{ic|.snapshots}} so it does not lead to the recursive mess. So your proposed layout seemed very similar to the current suggested layout. The real difference is which subvolume gets mounted at {{ic|/}}, but I did not find it explained anywhere on the Snapper page before I reverted the changes (I get it now from your user page). I also did not find a proper documentation of the openSUSE's layout - it seems to be just the product of their installer and the documentation only deals with the result, saying at most that [https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-snapper.html#sec-snapper-snapshot-boot the subvolume configuration must not be changed] for rollbacks to work.<br />
:::Now the openSUSE-specific elements: some Arch packages actually install software into {{ic|/opt}}, so the recommended layout should not suggest a separate subvolume for this path. Even more importantly, the pacman database is located at {{ic|/var/lib/pacman/local/}} and it must be rolled back along with the system, so there should be no separate subvolume for {{ic|/var}}. Instead, users should be encouraged to create (even nested) subvolumes for specific data directories under {{ic|/var}}, such as {{ic|/var/log}}, {{ic|/var/tmp}}, {{ic|/var/cache/pacman}}, {{ic|/var/lib/machines}}, etc.<br />
:::Finally, the suggested layout should not be GRUB-specific, there should be no recommendations regarding a boot loader. Sure it is useful to include non-trivial tips, but people may actually use a different boot loader.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:31, 4 December 2020 (UTC)<br />
<br />
::::Thanks for your detailed reply. I admit that I'm not knowledgeable on the intricate differences between distributions and shouldn't have made the changes without properly discussing them first.<br />
::::Yes, I get that the current layout is not [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|the one described in this section]] and indeed properly separates {{ic|/.snapshot}} and {{ic|/}}. The layout I proposed attempts to add some "niceties" such as supporting multi-distribution installations (complex and unnecessary, I agree) and bring the openSUSE layout here, which is a mistake, as you've pointed out.<br />
::::As for GRUB, since I use LUKS all the time and it's the only bootloader supporting encrypted {{ic|/boot}} on Btrfs on LUKS1, I really didn't think of any other possibilities.<br />
::::I will incorporate your recommendations to my user page and add a new section in [[Talk:Snapper]] pointing to those pages.<br />
::::Cheers -- [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:09, 4 December 2020 (UTC)<br />
<br />
:::::I've adopted [[Install_Arch_Linux_on_ZFS#System_datasets|Archlinux Root on ZFS layout]] to [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Create_subvolumes|my proposal]]. [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:56, 4 December 2020 (UTC)<br />
<br />
== Reflector Revert ==<br />
<br />
Hi Lahwaacz, about your [https://wiki.archlinux.org/index.php?title=Reflector&oldid=643749 revert], it seems like there's precedence for including AUR packages that replicate the code on the wiki. For example, in [[dash#Relinking /bin/sh]].<br />
<br />
In addition, I believe that there's value for linking the AUR package because it allows a simpler user experience where the AUR package is maintained for them. That way, if it is ever updated, they can easily fetch the update instead of religiously checking the wiki page (which most users probably don't do).<br />
<br />
Thanks!<br />
<br />
[[User:Denton-l|Denton-l]] ([[User talk:Denton-l|talk]]) 01:52, 7 December 2020 (UTC)<br />
<br />
:That precedence was only created by [https://wiki.archlinux.org/index.php?title=Dash&type=revision&diff=561587&oldid=518398 yourself]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 5 May 2021 (UTC)<br />
<br />
== firefox zoom ==<br />
<br />
"no reason to zoom manually, see HiDPI)" - fractional scaling doesn't work [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 26 December 2020 (UTC)<br />
<br />
:That should be explained in [[HiDPI#Firefox]] anyway. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:48, 26 December 2020 (UTC)<br />
<br />
::it's good to have this mentioned somewhere clearly so people know about it before they say "fonts on linux suck" [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 15:51, 29 December 2020 (UTC)<br />
<br />
== Intel GVT-g edits ==<br />
<br />
Hello Lahwaacz,<br />
<br />
I have noticed that you reverted one of the edits I have performed on [[Intel_GVT-g]].<br />
<br />
About this revert: [https://wiki.archlinux.org/index.php?title=Intel_GVT-g&oldid=648062 Windows problems are out of scope]<br />
<br />
While I understand that the ArchWiki is about ArchLinux, this article in particular mentions Windows in the introduction, and already includes another troubleshooting point about Windows. The issue I have encountered with the black bars is somewhat common, as I have found other people discussing it online, and I really fail to see why not including this piece of information in this article would be better than including it.<br />
<br />
Please, let me know your thoughts. If you think that the point can be improved, I will be happy to do that.<br />
<br />
Ciao,<br />
<br />
[[User:Wilcomir|Wilcomir]] ([[User talk:Wilcomir|talk]]) 09:14, 3 January 2021 (UTC)<br />
<br />
:Well, the existing section about a Windows problem is actually solved by configuring the Linux host. I think anything involving configuration or installation of programs in Windows is not appropriate for long troubleshooting sections. At most, they could be mentioned in a short reference to other sites which describe the problem in detail. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:34, 3 January 2021 (UTC)<br />
<br />
== <s>XDG configuration for Vim</s> ==<br />
<br />
Hi Lahwaacz,<br />
<br />
You have reverted the updated Notes for Vim on [[XDG Base Directory]], because "copy-pasted from a blog post".<br />
<br />
The problem is, not only is the configuration presented currently also copied from a blog post too, but is already 10 years old.<br />
<br />
Would it be OK, if we bring back the more up to date version? Or at least remove the obsolete one and leave link to newer?<br><br />
(Although I think a copy on wiki would be beneficial in case my blog ceases to exist)<br />
<br />
[[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 02:05, 12 January 2021 (UTC)<br />
<br />
:OK let's close this. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:49, 29 August 2021 (UTC)<br />
<br />
== Root on ZFS draft ==<br />
<br />
Hi, I submitted [https://github.com/openzfs/openzfs-docs/pull/104 a Root on ZFS draft] to official doc repo.<br />
<br />
In the draft, the following directories are separated from root filesystem:<br />
home,root,srv,usr/local,var/log,var/spool,var/tmp<br />
<br />
Is this appropriate for Arch Linux? Or do you have any suggestion on the draft?<br />
Any comment is appreciated.<br />
[[User:M0p|M0p]] ([[User talk:M0p|talk]]) 01:28, 23 January 2021 (UTC)<br />
<br />
== Re: undo GRUB - Common installation errors ==<br />
<br />
Concerning your undo of [https://wiki.archlinux.org/index.php?title=GRUB&diff=next&oldid=649799 Add the error message `Could not prepare Boot variable: No space left on device`)]<br />
Is there a better place to for this Information? One can find the solution in various forums, but I thought it could be helpful to have it in this wiki somewhere. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 12:51, 25 January 2021 (UTC)<br />
<br />
:The error message is not specific to the {{ic|/sys/fs/pstore/}} filesystem (which does not even seem to be used by default on Arch...) Where did you find that? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:16, 25 January 2021 (UTC)<br />
<br />
::I did not find anything Arch specific, but this post about Debian helped: [https://donjajo.com/fix-grub-efibootmgr-not-set-variable-no-space-left-device/ Post]. I also found something about [https://askubuntu.com/questions/1072618/could-not-prepare-boot-variable-no-space-left-on-device-grub-install-error-ef /sys/fs/efi/efivars/dump-*] The problem is that the actual efi-partition does not seam to be the problem, there is more than 70% space left. If there is better information to guide the user in the right direction that wuld be more helpful. This is what I found worked, but I admit that I don't know much about how grub operates. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 16:20, 25 January 2021 (UTC)<br />
<br />
:::This wiki ''is'' Arch specific so old posts about Debian or Ubuntu do not apply. Even if they did, this is hardly a ''common'' installation problem. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:29, 26 January 2021 (UTC)<br />
<br />
::::I know that, and would not have put it there if it didn't occur on my Arch Linux installation. If this is something that should not be documented in this wiki, I understand that. Is there any other place you would recommend? An issue for grub-install maybe? [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 22:24, 26 January 2021 (UTC)<br />
<br />
== Kernel Compilation time ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Kernel&diff=next&oldid=650896 link]<br />
<br />
I don't think we should judge information by what is obvious to experts.<br />
People might have experience with compilation of other programs, which mostly is fast, and then there is the kernel which takes forever to compile.<br />
I think it does not hurt anyone to make people aware of it.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:03, 6 February 2021 (UTC)<br />
<br />
:It is an unnecessary information without a definite answer which can even be [https://html.duckduckgo.com/html?q=how%20long%20does%20it%20take%20to%20compile%20Linux%20kernel searched elsewhere]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:23, 6 February 2021 (UTC)<br />
<br />
:: I disagree, with that argument nearly any tip and note is unnecessary. These things are intended to inform users about things that should be taken into consideration and that are different from the norm.<br />
:: Also do you search for the compilation time for every program you intend to compile? I don't.<br />
:: Furthermore this info is included, why not tell it to people directly on the start, so they don't read over it? <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:36, 6 February 2021 (UTC)<br />
<br />
:::If someone wants to compile the Linux kernel, they should obviously expect that it will take ''some time''. Stating that it "can take up to several hours" does not make sense without referring to a specific hardware. Obviously, it will take much longer on a poor laptop than on a powerful workstation with a many-core processor, but people can assume that themselves. Without a reference to a specific hardware, the note is unnecessarily discouraging because the compilation can be as fast as some tens of minutes - it is by far not the most expensive package to compile...<br />
:::As you said, people can find better notes later along with advices to enable parallel build etc. which is all that's needed IMO.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:03, 6 February 2021 (UTC)<br />
<br />
== Wayland style ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Wayland&diff=prev&oldid=650979 link]<br />
<br />
I think in the old version it was much easier to read the "source code", so I don't see why there can't be spaces between it.<br />
Things shouldn't be complicated more than necessary.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:11, 6 February 2021 (UTC)<br />
<br />
:Most templates on the wiki are written without spaces around the |. When we [https://github.com/archlinux/archwiki/pull/32 switch the editor], there will even be syntax highlighting. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:25, 6 February 2021 (UTC)<br />
<br />
== Bluetooth keyboard ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php/Bluetooth_keyboard link]<br />
<br />
On your last change you said "not specific to keyboards, all of this is already mentioned on the Bluetooth page", the point is that this is extremely relevant for bluetooth keyboard since it is required to perform the login! If this little piece cannot be duplicated I would suggest at least to leave a link saying "If you want to autoconnect at boot please refer to...". I'm new here and I would not touch it further, but please evaluate the suggestion (this is because after reading bluetooth keyboard page and not finding the solution I had to look for it on forums)<br />
<br />
{{unsigned|21:17, 20 February 2021|Stevexyz}}<br />
<br />
:Well, basically the whole page is flagged to be merged with the main [[Bluetooth]] page, so it's expected to be incomplete. Other tips may always be found on a more general page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:40, 21 February 2021 (UTC)<br />
<br />
== Re: Steam Needs to be online error ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Steam/Troubleshooting&diff=next&oldid=653073 link]<br />
<br />
The problem here is that DNS resolution in general works already (yes even outside browsers), i.e. <br />
<br />
dig media.steampowered.com<br />
<br />
would run successfully, but the Steam client couldn’t resolve it. The DNS request from 'dig' shows up in my nameserver’s log, the one Steam should send doesn’t. This indicates it might indeed a problem specific to Steam, and it’s not as easy as just say "go fix your DNS resolution", as it already may work correctly for everything but Steam.<br />
<br />
Additionally, at no point does [[Domain name resolution]] even mention nscd, so you effectively removed a fix/workaround for the problem from the Wiki. So I was definitely not "duplicating an article" here. [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 08:12, 22 February 2021 (UTC)<br />
<br />
:Could I please hear your opinion on this? I’d be happy to just add something along the lines of "if you made sure DNS resolution works but Steam still can’t resolve it, try additionally enabling the nscd service" to the Steam troubleshooting page. Unfortounately I don’t know why running the service helps, but I’d still like to give others an easier time finding this solution than I had myself. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 09:15, 28 February 2021 (UTC)<br />
<br />
::Hi, I'm sorry for the delay. Could you test if using a different program for DNS caching (e.g. [[systemd-resolved]]) instead of {{ic|nscd.service}} fixes the problem? If not, then it's probably not due to DNS - {{man|8|nscd}} actually caches more than just DNS. Also if you have a reference to some website where you found about nscd, it would be nice to add it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 28 February 2021 (UTC)<br />
<br />
:::No worries. Using [[systemd-resolved]] for DNS resolution (and caching I guess, I wasn’t aware it does that, too) was a thing I did try, but that didn’t fix it for me. The place I found out about nscd fixing it was actually the [https://bbs.archlinux.org/viewtopic.php?id=263356 Arch forums]. When I search the web for Steam in combination with nscd, all I can seem to find are more forum entries of people that don’t know why that fixes it either. I can try a bit to find out what nscd does to make it work, but I’m not too confident I will be successful. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 14:51, 28 February 2021 (UTC)<br />
<br />
::::Okay, so {{ic|nscd}} allows to [https://man7.org/linux/man-pages/man5/nscd.conf.5.html dis-/enable caching per service], and it’s indeed enabling it for {{ic|hosts}} that makes it work. That’s weird though, since [[systemd-resolved]] has caching enabled by default, and using it for resolution didn’t make {{ic|steam}} work for me. Leads me to think that I didn’t set it up correctly, although resolving via {{ic|dig}} *did* work. Since [[steam]] depends on [[Name Service Switch]], I tried resolving using {{ic|getent}} manually with nscd disabled, but that worked while steam did not. I’m not really sure what to make of this, since I have no idea how this low level networking/resolving stuff works really. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 15:39, 28 February 2021 (UTC)<br />
<br />
:::::Hmm, I don't know the details either. Steam needs the multilib packages so maybe that's part of the problem. Could you add your findings to the section and use [[Template:Expansion]] for the missing details? Maybe someone can figure it out. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:44, 28 February 2021 (UTC)<br />
<br />
::::::Sure, I can do that. I’ll probably need a minute to figure out how to use the template though, but I should have the time later today. Thanks for your input on this. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 17:56, 28 February 2021 (UTC)<br />
<br />
== Removal of website link ==<br />
<br />
Refers to this: https://wiki.archlinux.org/index.php?title=PipeWire&diff=next&oldid=653701<br />
<br />
I don't understand why that has to be removed. The official website should be always worth a mention, even if it is somehow mentioned in the text already.<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:02, 28 February 2021 (UTC)<br />
<br />
:The "See also" section is for additional links, it is not intended as a collection of all links used on a page. Adding links which are clearly mentioned in the appropriate place only clutters the list. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:24, 28 February 2021 (UTC)<br />
<br />
:: There are just three links and only one of them is really useful, the others could maybe even be removed as they link to old blog posts.<br />
:: I can only repeat myself, that things don't always have to be made more complicated than necessary.<br />
:: The official website is a central point which links to many more useful ressources, so it's one link for much information.<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:34, 28 February 2021 (UTC)<br />
<br />
== Removal of bootia32.efi generation procedure from X205TA install page. ==<br />
<br />
Those [https://wiki.archlinux.org/index.php?title=ASUS_x205ta&diff=596239&oldid=562734 instructions] were really straightforward and useful, imho in comparison present ones require too much material to be confident with. I think it's (paradoxically) way easier to generate the file than to configure a `grub.cfg` from zero to boot a live cd. Can we undo the edit? Otherwise we could put them in a new page or section in the GRUB page and link to them maybe. [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 05:07, 4 March 2021 (UTC)<br />
<br />
:If there is something wrong with the information on the [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Booting_64-bit_kernel_on_32-bit_UEFI general page], it should be improved instead of describing the same procedure in a different way on a completely unrelated page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:16, 6 March 2021 (UTC)<br />
<br />
:: I didn't know we had that info in the UEFI article. I think it could be appropriate to insert the [https://en.wikipedia.org/wiki/Template:See_also#Examples See also] archwiki equivalent (which I couldn't find) for UEFI page on top of the aforementioned section, what do you think? [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 13:28, 7 March 2021 (UTC)<br />
<br />
:::Well, the removed section was previously flagged with "Duplicates [[Unified Extensible Firmware Interface#Booting 64-bit kernel on 32-bit UEFI]]"...<br />
:::Also the laptops pages are usually related to most of the general pages on this wiki, adding all of them would be pretty useless. Users should not expect to find everything on a single laptop page, they should always check if there is a general page for their topic with more details.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:58, 7 March 2021 (UTC)<br />
<br />
== Re: Show how to use systemd/Timers with wg-quick@.service ==<br />
<br />
I don't think using service is the appropriate when you want to start Wireguard at boot. For most people connecting to a VPN is not exactly part system startup.<br />
A timer should more appropriate.<br />
[[User:ENV25|ENV25]] ([[User talk:ENV25|talk]]) 10:03, 11 April 2021 (UTC)<br />
<br />
:I don't see how OnBootSec=1min is more appropriate than an automatically starting service. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:19, 11 April 2021 (UTC)<br />
<br />
== USB flash installation medium (BIOS bootable) ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=next&oldid=673926 revert]: "making the partition bootable is discussed below"<br />
Do you mean installing syslinux and `dd` the [gpt]mbr with "discussed below"? This was not enought for my setup (Sandisk Ultra 64GB, Dell XPS 9370) to make the partition BIOS bootable. It did work right after I checked "Legacy BIOS Bootable" checkbox using gnome-disks.<br />
<br />
{{Unsigned|13:42, 30 May 2021 (UTC)|Auipga}}<br />
<br />
:Yes, that's what I meant. If it does not work, it should be fixed rather than providing a duplicate instruction without a reason. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:16, 30 May 2021 (UTC)<br />
<br />
== Systemd-networkd systemd-networkd-wait-online.service discussion modifications ==<br />
<br />
I'm not sure why you're reverting my edits.<br />
<br />
You said: "''empty ExecStart is explained in Systemd#Examples''"<br />
<br />
Exactly: Systemd#Examples clearly states "''As another example, in order to replace the ExecStart directive for a unit that is '''not of type oneshot'''''"<br />
<br />
'''systemd-networkd-wait-online''' is a oneshot service. By having the superfluous empty ExecStart you're just confusing people.<br />
<br />
Regarding the file naming, yes the name is irrelevant, but it's generally helpful to non-expert users to stick to canonical naming conventions.<br />
<br />
Please make sure you're on solid ground before reverting edits; you're just discouraging people from engaging with the Wiki. Thanks. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 16:51, 9 June 2021 (UTC)<br />
<br />
:{{man|5|systemd.service}} says: "Unless Type= is oneshot, exactly one command must be given. When Type=oneshot is used, zero or more commands may be specified."<br />
:So when a service is not oneshot, users ''must'' clear ExecStart before adding a modified command in the drop-in file. If a service is oneshot, they ''may or may not'' clear ExecStart, since the service may have multiple ExecStart commands.<br />
:In case of systemd-networkd-wait-online, I don't see why you would want to run multiple instances with different options: one to wait for ''all'' links (which is the default command) and another one to wait for ''any'' link (which is the command in the drop-in example). So clearing ExecStart really makes sense for systemd-networkd-wait-online.<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:44, 9 June 2021 (UTC)<br />
<br />
== Pacman: Install missing dependencies ==<br />
<br />
Hi. [https://wiki.archlinux.org/index.php?title=Pacman&type=revision&diff=690774&oldid=690762 "Pacman" Revision as of 21:50, 4 August 2021 (undo)] - maybe at least put that into [[System_maintenance#Avoid_certain_pacman_commands]]?<br />
<br />
[[User:Galeksandrp|Galeksandrp]] ([[User talk:Galeksandrp|talk]])<br />
<br />
:[[System_maintenance#Avoid_certain_pacman_commands]] already mentions {{ic|-Rdd}}. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:12, 14 August 2021 (UTC)<br />
<br />
== DPMS: "\033[9;0]" ==<br />
<br />
Hi. It seems that you removed {{ic|echo -ne "\033[9;0]"}} from [[Display Power Management Signaling|DPMS]]<br />
<br />
https://wiki.archlinux.org/index.php?title=Display_Power_Management_Signaling&diff=629705&oldid=625073<br />
<br />
[https://www.denx.de/wiki/view/DULG/SwitchOffScreenSaverAndBlinkingCursor A DULG page] and [https://unix.stackexchange.com/a/23636 a U&L post] brought me here.<br />
<br />
May I ask (1) if this method is still working; and (2) where is this escape sequence documented? [not found in {{man|4|console_codes}}]<br />
<br />
Thanks.<br />
<br />
{{Unsigned|05:23, 15 August 2021 (UTC)|PXf}}<br />
<br />
:[[Display Power Management Signaling#DPMS interaction in a Linux console with setterm]] says that setterm works by writing escape codes to the terminal device. The first subsection shows how to reverse-engineer the escape codes. Note that the escape codes are an implementation detail that users should not be concerned with, their documentation is certainly not our job. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:40, 15 August 2021 (UTC)<br />
<br />
== Linux console/Keyboard configuration ==<br />
<br />
Hi, you recently reverted my edit https://wiki.archlinux.org/index.php?title=Linux_console/Keyboard_configuration&oldid=693887. The reason I made that edit, was that I used to put my custom keymap in {{ic|/usr/local/share/kbd/keymaps/personal}} per the previous version of the wiki page. But this doesn't work with ''sd-vconsole'', as it's include files don't get loaded. Your suggested workaround by adding all required files using [[mkinitcpio#BINARIES and FILES|mkinitcpio BINARIES and FILES]] is rather tedious, as all the include files need to be in there, added by hand. This is done automatically by ''sd-vconsole'' if the file was put in {{ic|/usr/share/kbd/keymaps/}}. The reason I made this edit is due to https://bugs.archlinux.org/task/71788. See Giancarlo Razzolini's comment. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:43, 2 September 2021 (UTC)<br />
<br />
:It's just one custom file under {{ic|/usr/local}} and one entry in {{ic|FILES}}. What is so tedious about it? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:37, 2 September 2021 (UTC)<br />
<br />
:: It's not just one file. All the dependencies need to be included too under {{ic|/usr/share/kbd/keymaps/}}. There are quite a few in my case, when I just include ''us.map'' to modify it slightly. See the ''sd-vconsole'' hook script. That script has a part where it finds all the dependencies of a keymap.<br />
<br />
:: * ''/usr/share/kbd/keymaps/i386/include/compose.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/euro1.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-keys-bare.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-with-alt-and-altgr.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/qwerty-layout.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/personal.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/us.map''<br />
:: * ''/usr/share/kbd/keymaps/include/compose.latin1''<br />
<br />
:: [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 12:01, 2 September 2021 (UTC)<br />
<br />
::: I moved this to the talk page so I remember it and others can discuss too. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:18, 4 September 2021 (UTC)<br />
<br />
::: Oh, I see. In that case I suggest we add a tip like this:<br />
::: {{Tip|If you use the {{ic|sd-vconsole}} [[mkinitcpio#Common hooks|mkinitcpio hook]] instead of {{ic|keymap}}, keymaps located under {{ic|/usr/local}} as well as their dependencies from {{ic|/usr/share/kbd/keymaps}} need to be manually specified in the {{ic|FILES}} array in {{ic|mkinitcpio.conf}}. On the other hand, custom files located in {{ic|/usr/share/kbd/keymaps}} will be added automatically when configured in {{ic|/etc/vconsole.conf}}.}}<br />
::: Because this is relevant only for people using the {{ic|sd-vconsole}} hook and otherwise it does not make sense to pollute {{ic|/usr/share/kbd/keymaps}} with custom files.<br />
::: — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:55, 5 September 2021 (UTC)<br />
<br />
== cow_* ==<br />
<br />
Hi Lahwaacz. About the [https://wiki.archlinux.org/index.php?title=Archiso&diff=next&oldid=692981 how/why issue] (there will be no more &lt;!-- --&gt;). What if, for once, that I want to install some large packages after booting archiso, and would not bother modifying packages.x86_64 and building again? [https://www.memesmonkey.com/topic/works+on+my+machine <s>''on my machine''</s>] Darren "Un1Gfn" "[[User:PXf|PXf]]" Ng ([[User talk:PXf|talk]]) 08:18, 12 October 2021 (UTC)<br />
<br />
:It is a subsection of "Tips and tricks", not "Troubleshooting", so it should start with a clear motivation saying ''why'' the tip is useful, rather than an error message that the user has no idea if they will face or not. If you have such description, feel free to rewrite the section. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 05:42, 13 October 2021 (UTC)<br />
<br />
::What about making it a subsection of "[[Archiso#Troubleshooting|Troubleshooting]]" and renaming it to {{ic|partition / too full}}? [[User:PXf|PXf]] ([[User talk:PXf|talk]]) 06:45, 13 October 2021 (UTC)<br />
<br />
:::It's better to motivate it as a tip/trick rather than solve the problem after it happens. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:48, 13 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
(Undo revision 699881 by Oliver (talk) - installing arch-install-scripts does not get the image to "the same footing" as the archiso, even installing something for the first time is not an excuse to violate Help:Style#Package management instructions)<br />
<br />
'the same footing' may be poor choice of wording maybe but it's also not false. You are in a SIMILAR place, not 'exactly identical to the dot' e.g. same footing<br />
<br />
but 'installing something for the first time' is NOT what is going on here really. If we quote the style guide:<br />
<br />
''every Arch user should know pacman's article by memory''<br />
<br />
<br />
The thing is, this is NOT an Arch user yet. They have no idea what's going on, how to do stuff and just want to get started and installed. You can't expect _new_ not-yet-a user, to figure out everything in a daunting installation; by being a smart-bum about it. Yes, the style guide is completely correct on all other points. But I would think that this is the exception, rather then the rule. Help your new users a little. Introduce them gentle with open arms. From a 'first UX kind of way, this is horrible to treat your potentially new users.<br />
<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 17:40, 26 October 2021 (UTC)<br />
<br />
:We use the same convention on the [[Installation guide]] itself. They should read the [[pacman]] page to learn how to install packages as soon as possible, so why not right when they use it for the first time? There is a gentle link to "[[install]]" before the package name, so the clueless user will follow the link and learn something. They will not learn anything by copy-pasting a quick one-liner. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 26 October 2021 (UTC)<br />
<br />
Yes, you ARE right, however; this is the install guide (relatively speaking) Let them install the system first with a gentle nudge; THEN force them to learn stuff :p<br />
<br />
Again, I understand the policy and the reasoning behind it very much so; but it's those first few steps that are the hardest. It's birds vs humans I suppose; birds throw their children out of their nests to teach them to fly (or die); Humans raise their children first in a more gentle manor. Is arch really the 'l337 fly or die, rtfm n00b' kind of distro?<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 18:25, 26 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
skip the rsync protocol<br />
<br />
As per my 'commit message' The user is confronted with the following:<br />
WARNING: failed to rate rsync download (rsync://mirror.erickochen.nl/archlinux/community/os/x86_64/community.db): [Errno 2] No such file or directory: 'rsync'<br />
<br />
You really think we should not reflect this in the documentation for now, until this dependency is actually properly resolved in the package? (could be weeks?)<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 18:32, 26 October 2021 (UTC)<br />
<br />
:Do you get this warning even with the {{ic|--protocol http,https}} that I added in the mentioned change? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:49, 26 October 2021 (UTC)<br />
<br />
Nope, that actually fixes it. I probably got it from an older version of the {{Pkg|reflector}} page which didn't explicitly list it. Btw, is http(s) preferred even over rsync? Is rsync still the 'modern way' to do it?<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 18:54, 26 October 2021 (UTC)</div>Oliverhttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_via_Docker&diff=700022Install Arch Linux via Docker2021-10-26T18:49:50Z<p>Oliver: Improve readability</p>
<hr />
<div>[[Category:Installation process]]<br />
{{Style|Formatting does not comply to the guidelines, see [[Help:Style]].}}<br />
<br />
This document is a guide for installing [[Arch Linux]] using the official [Arch Linux docker](https://hub.docker.com/_/archlinux). For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation [https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html]. A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available. Furthermore a working [[Docker]] setup on the host is required. While technically it is certainly possible to use any qemu supported host to install Arch with, this guide will not cover this however.<br />
<br />
== Pre-installation ==<br />
<br />
This guide assumes that the host system is already pre-configured with regards to normally expected things. E.g. the time is setup correctly, internet connection is working normally, EFI mode if required is setup correctly etc.<br />
<br />
=== Prepare an installation medium ===<br />
<br />
The installation requires a target directory to which Arch Linux will be installed. Any writable directory can be used, but it is quite likely that the target directory has a partition or volume mounted that will server as the root disk.<br />
<br />
==== Full disk partitions ====<br />
<br />
If a full disk is being used as a target, it may need to be formatted. For details see [[Installation guide#Partition the disks]] as the same partitioning instructions and order can be followed from there. All the same restrictions and requirements as from there apply as well.<br />
<br />
Likewise, the new disk will also needed to be formatted. The instructions from [[Installation guide#Format the partitions]] can be used for this as well.<br />
<br />
==== Volumes ====<br />
<br />
When using filesystems such as [[btrfs]] or zfs, filesystem volumes are an option to use. Depending on what filesystem is used, creating them uses their own list of commands. In this guide, btrfs will be used as an example.<br />
<br />
First, a root volume for Arch Linux is created. This command assumes the current working directory is the btrfs root volume (subvolid=5), but anywhere could be used. If a different location is used, within an existing hierarchy, keep this in mind when later defining fstab and similar. Also note, that as the Arch Linux specific volume is created on a mounted (root) volume, it could be the case that the underlying stack is using (full)disk encryption.<br />
<br />
# btrfs subvolume create "arch_root"<br />
<br />
{{Note|To get the root volume, mount the btrfs with the {{ic|1=subvolid=5}} option.}}<br />
<br />
=== Mount the file systems ===<br />
<br />
The following section assumes the location Arch Linux will be installed into ''/tmp/target''. It is thus required that the partition is thus mounted there. Using a btrfs subvolume called '''arch_root''', with ''autodefrag'' and ''LZO compression'' enabled would look as:<br />
<br />
# mkdir -p /tmp/target<br />
# mount /dev/''disk'' /tmp/target -o subvol=arch_root,compress=lzo,autodefrag<br />
<br />
The instructions from [[Installation guide#Mount the file systems]] can be used for this as well.<br />
<br />
== Installation ==<br />
<br />
=== Launching the container ===<br />
<br />
The remainder of the installation will be done inside a docker container, abbreviated with ADC, Arch Docker Container.<br />
<br />
# docker run \<br />
--env PS1="ADC(\#)[\d \T:\w]\\$ " \<br />
--interactive \<br />
--privileged \<br />
--rm \<br />
--tty \<br />
--volume "/tmp/target:/target" \<br />
"index.docker.io/library/archlinux:latest" /bin/sh<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. In the docker container we first install [[reflector]], which updates the mirror list by choosing 70 most recently synchronized HTTPS mirrors and sorting them by download rate. [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/system/reflector.service]<br />
First we have to [[install]] [[reflector]] in the docker container to be able to use it.<br />
<br />
# reflector [--country <country>] \<br />
--latest 5 \<br />
--protocol http,https \<br />
--save "/etc/pacman.d/mirrorlist" \<br />
--sort rate<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. Ensure to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
To put the Docker image on a similar footing as the installation medium, the {{Pkg|arch-install-scripts}} package must be installed first.<br />
<br />
With this completed, the actual installation can be followed starting with the section [[Installation guide#Install essential packages]].<br />
<br />
== Configure the system ==<br />
<br />
Follow the instructions in [[Installation guide#Configure the system]]. Replace {{ic|/mnt}} with {{ic|/target}} as appropriate.<br />
<br />
== Reboot ==<br />
<br />
Exit the docker container by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R "/target"}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
With a correctly setup boot loader, a reboot should now be possible into the freshly installed Arch Linux.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=User_talk:Lahwaacz&diff=700021User talk:Lahwaacz2021-10-26T18:32:07Z<p>Oliver: /* Install Arch Linux via Docker */ missing signoff</p>
<hr />
<div>== bot checking links after move ==<br />
<br />
Hi, re [[Talk:Touchpad Synaptics#adding libinput alternative]]. [[Touchpad Synaptics]] has 100+ backlinks and the more important ones - a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of [[Touchpad Synaptics]] and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:36, 26 September 2015 (UTC)<br />
<br />
:Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a [[UUID]] page, which was later generalized and renamed to [[Persistent block device naming]] and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace <nowiki>[[pacman|Install]]</nowiki> with <nowiki>[[Install]]</nowiki> etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:01, 26 September 2015 (UTC)<br />
<br />
::Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [https://wiki.archlinux.org/index.php/Special:WhatLinksHere/Beginners'_Guide]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:02, 26 September 2015 (UTC)<br />
<br />
== mkosi ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=Systemd-nspawn&diff=0&oldid=491975 revert]: You can use mkosi also to create a container/directory tree (-t directory). So it can do the same and more. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 11:33, 1 October 2017 (UTC)<br />
<br />
:Alright, how is the "more" relevant to systemd-nspawn though? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:30, 3 October 2017 (UTC)<br />
<br />
::Hi, mkosi let's you create images (or directory trees) of various different distributions and allows you to do things like setting the root-password or installing additional packages. systemd-nspawn alows you to boot such images/directory trees. So I thought mentioning mkosi as alternative to manually creating a container with pacstrap or debootstrap would be worth it. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 22:23, 5 October 2017 (UTC)<br />
<br />
== Waking from suspend with USB device ==<br />
<br />
Hi Lahwaacz, thanks for your input on this topic.<br />
Can you help me a bit further, I know the USB host controller and the USB device are different things but I thought that enabling the host controller was not necessary anymore, see [https://www.spinics.net/lists/linux-usb/msg53661.html].<br />
In my case all the {{ic|driver/*/power/wakeup}} are all enabled by default and the {{ic|/proc/acpi/wakeup}} as well.<br />
Anyway I have added a step in my explanations to identify the path awaiting for more clarity.<br />
<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 21:57, 16 January 2018 (UTC)<br />
<br />
:Hi, thanks for the link, it's entirely possible that something changed since the section was written. However, in my case only the keyboard device has wakeup enabled by default: {{bc|<nowiki><br />
$ for f in /sys/bus/usb/drivers/usb/*/power/wakeup; do echo "$f: $(cat $f)"; done<br />
/sys/bus/usb/drivers/usb/1-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/2-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-11/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-12/power/wakeup: enabled<br />
/sys/bus/usb/drivers/usb/3-13/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-4/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb2/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb4/power/wakeup: disabled<br />
</nowiki>}}<br />
:But in practice it seems to wake up the system even without the host controllers enabled for wakeup... It might also depend on some BIOS/firmware settings but if it works by default on most systems then I think the host controller settings could be removed again.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:14, 19 January 2018 (UTC)<br />
<br />
== Are supported local/remote destinations important for choosing a backup program? ==<br />
<br />
You [[Special:Diff/525550|reverted]] my edit adding supported backup destinations to [[Synchronization_and_backup_programs]]. This is puzzling to me. Here are some thoughts:<br />
* if choosing any backup program, the ability to send the backup off-site vs only on a local disk is a key feature consideration. Perhaps *the* key feature: one helps me recover in case my house gets burglarized or burns down, and the other does not. This is a much more important feature consideration than, say, whether the program is written in Go or Mono (something that has a full column). I think it's hard to disagree on that.<br />
* Given this, I am very puzzled you would use the term "useless" in the revert message.<br />
* I assume you didn't like that the table got even bigger (it didn't fit into the layout even before). I don't like it either, but perhaps the revert should have said "can you put this somewhere else, not in this already-too-big table?"<br />
* On a personal note, when I provide feedback or give opinion on somebody else's work, I'd like to be constructive and kind, instead of aggressive and putting people down. Just a thought. Thanks for listening.<br />
<br />
[[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 17:38, 11 June 2018 (UTC)<br />
<br />
:No because you can use any remote back-end with any backup application by just running one command / writing the backups to a [[FUSE]] (if available).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:39, 12 June 2018 (UTC)<br />
<br />
::Hmm, by that reasoning we don't need the Arch package repository, as long as we have source code and makepkg. Or Perl, if we have bash and awk. But even then, and if all the fuse backends existed (I doubt they do), and if it were easy to set all of them up (another thing I doubt), do you indeed believe that running something written to read/write local files will be just as efficient backing up gigabytes of data to a remote repository as something that is specifically optimized for that use case? Note that backing up, say, daily, a typical hard drive via tpyical consumer broadband is still quite a bandwidth challenge in many places today. What about we add this info, and remove (or merge) some other columns to make the table smaller? {{Unsigned|18:08, 12 June 2018|Jernst}}<br />
<br />
:::Your comparisons don't make sense. Mind the slash in my response, you do not need a FUSE implementation, a simple CLI suffices. You do not need to "set all of them up", you only need one. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 18:47, 12 June 2018 (UTC)<br />
<br />
::::If you ever attempt to help a normal user set up a reliably-working off-site backup strategy, think of this discussion. In the meantime, this is all the time I'm going to spend on a discussion that has such repeated gems in it as "makes no sense" without explaining why you think so. Have a nice day. [[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 18:54, 12 June 2018 (UTC)<br />
<br />
== The pip section in [[Python package guidelines]] ==<br />
<br />
Hi, you wanted the warning about using pip or wheels restored but accidentally(?) reverted my whole set of changes. I redid them, leaving the warning in place. – [[User:Flying sheep|flying sheep]] 08:17, 8 March 2019 (UTC)<br />
<br />
:Full revert was intentional, because the "wheel" section is not a full replacement for "pip" because there are packages which don't provide wheel files. As I said in the edit summary, there is no reason to recommend one or the other due to the warning. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 8 March 2019 (UTC)<br />
::That still doesn’t explain why you reverted the first part, that had nothing to do with the pip/wheel section and simple improves the files.pythonhosted.org URLs. I restored that one while we’re discussing the pip/wheel section. And about that: There’s no reason to use pip for anything else, and pip is only used because some people (me included) didn’t understand that you can install most wheels by just extracting them to the correct location. So what do you think is missing from my wheels section that the former pip section had? – [[User:Flying_sheep|flying sheep]] 11:41, 11 March 2019 (UTC)<br />
<br />
:::If you didn't notice, the page includes "guidelines" in the title. So the page should contain only common and recommended ways to do things, not everything that is possible to do. If you think that your way to install "wheels" should be followed by everybody, feel free to discuss it on the talk page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:26, 11 March 2019 (UTC)<br />
::::Well, extracting static archives sounds much more recommended than running pip with like 7 options to make it behave. I added a talk item: [[Talk:Python package guidelines#Remove_pip_section_in_favor_of_wheels_section?]] – [[User:Flying_sheep|flying sheep]]<br />
<br />
== wpa_supplicant ==<br />
<br />
Regarding https://wiki.archlinux.org/index.php?title=WPA_supplicant&diff=577215&oldid=577167, one person ran into this problem in March of this year and spent too much time diagnosing it:<br />
<br />
https://bbs.archlinux.org/viewtopic.php?id=244950<br />
<br />
It took me a few days to find the problem. I want to make sure the next time someone encounters it, they easily find relevant information about what the cause is. Since you've reverted my edits to both netctl and wpa_supplicant, what do you suggest?<br />
<br />
--<br />
<br />
[[User:Pooryorick|Pooryorick]] ([[User talk:Pooryorick|talk]]) 08:24, 18 July 2019 (UTC)<br />
<br />
== F2FS and GRUB ==<br />
<br />
Hello. :) I'm here to address a recent disagreement. I noticed a reversion of my edit regarding the F2FS filesystem, in particular regarding the configuration file to edit (with you representing /boot/grub/grub.cfg and me representing /etc/default/grub). I run F2FS on my daily driver with an encrypted root filesystem and encrypted boot on a separate partition, and have never had to touch grub.cfg. I only automatically generate it. It's possible to use either, but /etc/default/grub would make more sense as a recommendation in my mind because grub.cfg has the potential to be overwritten during updates, whereas /etc/default/grub doesn't. <br />
<br />
If there's a compelling reason to use grub.cfg over /etc/default/grub, please let me know. ^^ I'm always eager to learn more about Arch. I don't want to get in a reversion war so I've left your change untouched for the time being.<br />
<br />
[[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 00:17, 8 September 2019 (UTC)<br />
<br />
:The reason is explained in the section: "If GRUB is used with an unsupported filesystem it is not able to extract the UUID of your drive so it uses classic non-persistent /dev/sdXx names instead." If it does not apply to F2FS, it should be made clear. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:29, 8 September 2019 (UTC)<br />
<br />
::You can specify UUID's in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, so my proposed solution would work for F2FS and other unsupported filesystems, without the burden of manually editing grub.cfg. If there's anything I need to clarify or something else I'm missing, just let me know. :) [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 19:37, 8 September 2019 (UTC)<br />
<br />
:::The {{ic|1=root=}} parameter is not supposed to be in GRUB_CMDLINE_LINUX_DEFAULT, regardless if UUID is used or not. ''grub-mkconfig'' automatically detects the root filesystem and adds the appropriate {{ic|1=root=}} parameter based on GRUB_DISABLE_LINUX_UUID. In any case, your change to the paragraph does not make sense. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:02, 8 September 2019 (UTC)<br />
<br />
::::It could simply be because I use full disk encryption, and adding a kernel parameter for the encrypted disk's UUID is correct in that situation. You're more experienced with contributing to the wiki, so I guess I'll defer to your judgment. It felt like a reasonable edit and solution to me and I don't see the downside to including it in GRUB_CMDLINE_LINUX_DEFAULT. [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 05:38, 9 September 2019 (UTC)<br />
<br />
== dracut executable link ==<br />
<br />
Hello, your last edit on the dracut page (https://wiki.archlinux.org/index.php?title=Dracut&oldid=596388) that undid my 'Link to direct "make executable" section for executable link' commit states: "the redirect executable points exactly to that section", but it doesn't. Following the [[executable]] link just points to the top of the Help:Reading page.<br />
<br />
{{unsigned|17:06, 28 January 2020|Krathalan}}<br />
<br />
:In that case your browser probably does not work correctly, because the redirect [https://wiki.archlinux.org/index.php?title=Executable&redirect=no really points to the section]. Or MediaWiki, there was a bug several years ago... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 28 January 2020 (UTC)<br />
<br />
:: How strange... thanks for pointing that out. It does indeed appear to be some issue with my Firefox configuration. [[User:Krathalan|Krathalan]] ([[User talk:Krathalan|talk]]) 19:51, 28 January 2020 (UTC)<br />
<br />
== Getting install.php work in DokuWiki ==<br />
<br />
Hi, than you for having undone my contribution and pointed to the right solution on [[Dokuwiki#Configuration]]. Indeed I had read this solution before, but I was misled by the condition "if you are using lighttpd or nginx and your PHP version is lower than 7": as I use Apache with php v. 7.4.3 I didn't take it into account. Do you know what a correct rephrasing could be? Maybe it should be deleted?<br />
<br />
Also, I think that, at the end of this same section, one should add something like "verify that {{Pkg|php-gd}} is installed and restart {{ic|php-fpm.service}}".<br />
<br />
Naturally I can do it myself, but I prefer to ask before.<br />
[[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 17:31, 19 February 2020 (UTC)<br />
<br />
:Hi, apparently it depends on whether you had {{ic|open_basedir}} set previously or not. I've changed the page, feel free to update the gd extension. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:16, 19 February 2020 (UTC)<br />
<br />
::Thank you! However, while, I didn't have {{ic|open_basedir}} set previously, I couldn't access ''install.php''. I suspect there is another thing to do, since the configuration editor in DokuWiki complains that it cannot modify the configuration files although ownership and permissions are correctly set for the relevant symlinks, directories and files, and so is {{ic|open_basedir}}. However I can edit my pages. Maybe a return from a new user with a fresh installation would be more useful, though. [[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 08:20, 20 February 2020 (UTC)<br />
<br />
== Dead link in Simple stateful firewall#See Also ==<br />
<br />
Hi, Jakub. I am about [https://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&diff=599725&oldid=599717 this] edit. I tried to follow that link one more time and it is not require entering captcha. I am not see any content limitations and my colleague (he uses Tor) does not see them too. I am not sure how it works, so I leave it on your descision. -- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 14:29, 1 March 2020 (UTC)<br />
<br />
:Well, maybe it depends on the location from which the request comes. But I don't know how it works either... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:33, 1 March 2020 (UTC)<br />
<br />
::my guess is it returns captcha for crawlers only -- [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 01:59, 2 March 2020 (UTC)<br />
<br />
:::I'm getting it in my browser... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 2 March 2020 (UTC)<br />
<br />
== SystemD user units depending on graphical session ==<br />
Hi,<br />
regarding reverting my addition to [[Systemd/User]], could you please explain why? I referenced [[https://www.freedesktop.org/software/systemd/man/systemd.special.html]] which directly contradicts what you said in your summary.<br />
<br />
{{unsigned|19:53, 5 May 2020|Fuero}}<br />
<br />
:The note in [[Systemd/User#How it works]] still applies - systemd services are never per-session, but per-user. The service does not magically get the correct DISPLAY or WAYLAND_DISPLAY variable, it does not work if you have multiple sessions per user, etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:45, 6 May 2020 (UTC)<br />
<br />
== Plymouth ==<br />
<br />
Actually with just Plymouth it does not work properly. Even 0dd17y had the same issue in https://bbs.archlinux.org/viewtopic.php?id=220900.<br />
<br />
The reason I did not file a bug report is that it is anyway fixed in the git version and the latest release (0.9.4) is around 2 years behind master<br />
<br />
{{unsigned|09:50, 6 May 2020|M.Srikanth}}<br />
<br />
:So if you don't have to file a bug report, add a full troubleshooting entry or at least properly reference your inline note instead of resorting to plain "if that does not work, try this instead". -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:15, 6 May 2020 (UTC)<br />
<br />
== [Bitcoin core] build the code and run the test suites ==<br />
<br />
Hello,<br />
<br />
This week, I managed to build the Bitcoin code and run all the test suites with the help of this page: https://jonatack.github.io/articles/how-to-compile-bitcoin-core-and-run-the-tests<br />
<br />
Archlinux has two particularities:<br />
* being in rolling release, it takes to manually use the library {{ic|Berkeley DB (BDB) v4.8}}<br />
* the {{ic|/tmp}} directory is by default limited to half the size of the Ram<br />
<br />
For these reason, maybe it could be interesting to have a page in the wiki to explain how to build the Bitcoin core?<br />
<br />
Cheers,<br />
<br />
Thomas<br />
<br />
[[User:Thomasb|Thomasb]] ([[User talk:Thomasb|talk]]) 20:29, 9 May 2020 (UTC)<br />
<br />
:I don't think that this is useful. There is the {{AUR|bitcoin-core-git}} package and nothing more should be needed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:53, 26 May 2020 (UTC)<br />
<br />
== Double linefeed results in extra line ==<br />
<br />
If you look at templates that end with double linefeed before noinclude this would result in extra line in resulting page.<br />
<br />
It may be a minor point but since you are perfectionist about wikitext I should mention this is a tradeoff and it results in slightly worse result.<br />
<br />
Removing just one linefeed removes the problem while still allowing it to not jumble all the tags into same line.<br />
<br />
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:30, 11 May 2020 (UTC)<br />
<br />
:If this is about [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=next&oldid=612179], the spaces I added back are not included when the template is used elsewhere, because the spaces are inside the noinclude tags. The extra space is only on the template page itself, but it does not result from template inclusion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:41, 11 May 2020 (UTC)<br />
<br />
::OFC, I mean the template page render has extra line. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 21:21, 11 May 2020 (UTC)<br />
<br />
:::I agree with [[User:Svito|Svito]], isn't it good to delete the extra blank lines? -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 05:39, 12 May 2020 (UTC)<br />
<br />
::::OK, let's do it. [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=616382&oldid=612181] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:47, 26 May 2020 (UTC)<br />
<br />
== Re: lighttpd: remove python2 version ==<br />
<br />
Instead of removing the example we could as well add an example using a Python3 library like https://pypi.org/project/flup6/.<br />
<br />
{{unsigned|15:23, 18 May 2020|Gruentee}}<br />
<br />
:Feel free to add it if you find it useful. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:56, 18 May 2020 (UTC)<br />
<br />
== Xbindkeys removal ==<br />
<br />
Hi, just wondering why you [https://wiki.archlinux.org/index.php?title=Xbindkeys&diff=617675&oldid=617670 removed my edit] from [[Xbindkeys]]? The xbindkeys page has a number of quick tips but no mention of how to bind anything to the Print Screen key so I thought it would be useful to add. -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 02:27, 3 June 2020 (UTC)<br />
<br />
:Giving examples for all keys on the keyboard is useless, there is [[Xbindkeys#Identifying keycodes]] which teaches how to find the keycodes and keysyms of any key. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 3 June 2020 (UTC)<br />
<br />
:: So how come you left the examples for the volume up/down and brightness? What is different between those examples and a screenshot example? Aren't more examples better to save people from hunting all over the place trying to piece things together themselves? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 14:03, 4 June 2020 (UTC)<br />
<br />
:::The difference is that when it comes to volume control, there are 1 or 2 options for the 99% most common cases, but for screenshot taking there are dozens of different options. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:15, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for edit to XDG Base Directory page regarding python_history ==<br />
<br />
I understand the justification for reverting the change I made, however I would like to point out that similar entries on the page (such as Maven) also have instructions for what contents to put in files (even though there is native documentation for those settings). Additionally, it took me a bit of re-reading on the linked Python documentation to reason out how the documentation's example needed to be modified, since it's not clear from the Python documentation whether placing such code in the PYTHONSTARTUP file will actually ''override'' the default behavior. [[User:Varriount|Varriount]] ([[User talk:Varriount|talk]]) 20:44, 20 June 2020 (UTC)<br />
<br />
:Even maven's note can be [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=631704&oldid=631630 shortened]. The notes in the table must be as short as possible, there is no place for extended explanations or long code snippets like in the upstream documentation. If the Python's documentation is not clear enough, I don't think any note in a massive convoluted table will ever be better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:47, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for Backlight page ==<br />
<br />
Hi, you reverted my change to [[Backlight]] page that mentioned WIP patches for controlling OLED panel brightness. I don't really understand justification for reverting it since currently the page says that OLED brightness can be controlled only by changing gamma ramp. That is wrong - since it's not the only way - these panels can control brightness with a PWM. Moreover controlling brightness with gamma ramp is not optimal - it essentially reduces dynamic range, i.e. at 50% you have 7 bits per pixel, at 25% - 6 bit per pixel, etc. That results in banding artifacts at lower brightness level.<br />
<br />
As far waiting for the patches to be merged before mentioning it there - it'll take ~3-6 months (yes, that's the process) and I haven't found *any* reference to these changes on the internet - everyone recommends using gamma ramp instead of fixing it properly. I'm absolutely sure that having information about these patches would not hurt [[User:Anarsoul|Anarsoul]] ([[User talk:Anarsoul|talk]]) 15:56, 30 June 2020 (UTC)<br />
<br />
:Linking to a repo which which has 2 custom commits on top of some arbitrary development version of the Linux kernel tree is not helpful for users. Nobody will compile directly from this repo which is already significantly outdated compared to recent kernel versions and there is no indication if the patches actually work with newer (or older) kernels. We can mention the PWM control as a general concept though. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:32, 12 August 2020 (UTC)<br />
<br />
== Automatic template correction ==<br />
<br />
Per [[Help:Template#Style]], templates should be used with the capitalization shown in the examples in their pages, so {{ic|&#123;{AUR&#124;...}} is correct, while {{ic|&#123;{aur&#124;...}} is not.<br />
<br />
However, there are pages that don't respect that rule (e.g. [[Android_Debug_Bridge]] until recently).<br />
<br />
I beleive this correction should be easy to implement using a bot. What do you think?<br />
<br />
{{unsigned|07:24, 25 August 2020|Relrel}}<br />
<br />
:Yes, this should be easy, but the bot should not make a huge amount of simple style-only changes - they should be combined with corrections for more complex rules. Anyway, there is an idea to create a [https://github.com/lahwaacz/wiki-scripts/issues/22 style linter] for the ArchWiki rules. Would you like to help? ;-) – [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:21, 25 August 2020 (UTC)<br />
<br />
== Failed to create tun device ==<br />
<br />
I don't understand your reason for [[https://wiki.archlinux.org/index.php?title=NetworkManager&diff=0&oldid=634880 removing my section in NetworkManager]]. Could you elaborate?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 07:40, 11 September 2020 (UTC)<br />
<br />
:You can't use [[systemd-networkd]] and [[NetworkManager]] at the same time. Even if you don't have any ''.network'' file for systemd-networkd, you can't solve NetworkManager's problems with systemd-networkd. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:43, 11 September 2020 (UTC)<br />
<br />
::Ok, thanks, in this case it solved the error I got. Now the VPN works. Do you have an idea about how to solve it without systemd-networkd?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 22:27, 11 September 2020 (UTC)<br />
<br />
:::You should really fix the permission problem for {{Pkg|networkmanager-openvpn}}. The tun interface should be managed by OpenVPN which needs rights to create it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 12 September 2020 (UTC)<br />
<br />
::I don't think this statement is entirely correct. [[systemd-networkd]] and [[NetworkManager]] can happily co-exist together if they are managing different interfaces. I unfortunately don't have a reference to point to this, but I came across this being mentioned a couple of times on forums. I personally use [[NetworkManager]] on my laptop to handle wifi, while [[systemd-networkd]] is in control of virtual ethernet and bridges for all my [[systemd-nspawn]] instances. [[User:Romstor|Romstor]] ([[User talk:Romstor|talk]]) 03:24, 12 September 2020 (UTC)<br />
<br />
== [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&oldid=636526/ XDG Base Directory]: Undo revision 636525 ==<br />
<br />
Dear Lahwaacz,<br />
<br />
maybe my changes were to rushed and from my point of view only. But I have two points to consider:<br />
<br />
# If I put the quotes around my vimrc and source it from my .bash_profile, I get the vim-error E471 (Argument required). Without quotes, this doesn't happen. So this change based on experience.<br />
# The rtp should includes directories, which are needed at runtime. (in plain vim e.g. ~/.vim). This is not a typical configuration directory. My mistake was, that I supposed that everyone put their vim plug-ins in $XDG_DATA_HOME and not in $XDG_CONFIG_HOME, because from my point of view a plug-in doesn't belong to the configuration. Maybe it is a good idea to add a remark, which explains the addition of $XDG_CONFIG_HOME to the rtp.<br />
<br />
[[User:Grrr|Grrr]] ([[User talk:Grrr|talk]]) 13:53, 26 September 2020 (UTC)<br />
<br />
# Quotes are there because $XDG_CONFIG_HOME may contain spaces.<br />
# It's not only about quotes - the runtimepath has subdirectories for color schemes, keymaps, autoload scripts etc.<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 26 September 2020 (UTC)<br />
<br />
== Readability in Wiki ==<br />
<br />
I noticed that you and the other admins and moderators often want sentences to continue endlessly, without line breaks.<br />
For example in the introduction of [[Wayland]].<br />
<br />
I think it would be better to have more seperated sentences, so it is easier to read and "important" information is easier visible for people.<br />
I don't know who is responsible, but maybe some options in MediaWiki (or whatever this wiki software is) could be changed as well, to make make line breaks etc. easier and reduce the height-space (if you know what I mean) between sentences, so it looks better, even though line breaks are used.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:38, 15 October 2020 (UTC) G3ro<br />
<br />
:I don't know exactly what you mean. Is it about the readability of the rendered HTML or the "source code" of the page? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:15, 15 October 2020 (UTC)<br />
<br />
:: Well I guess it can be about both. But mainly it is about what people see on the page.<br />
:: There are three seperate topics I mentioned:<br />
<br />
:: 1. Use line breaks: I would like to use more line breaks, because if you have long sentences that are written after each other without line breaks, it gets "harder" to recognize when the next sentence starts.<br />
:: While I agree to what you said somewhere, that sentences that belong directly together, should be written in one "paragraph", it would be useful for sentences that cover (slightly) different "topics" to be visibly parted.<br />
<br />
:: 2. Adjust margin options: I notice that when line breaks are used, there is a vertical space added between two sentences. Just like in this post. If you would use line breaks more often, this is a little too much spacing in my oppinion.<br />
<br />
:: 3. Potential options to make line breaks easier: It would be very convenient if a line break in the source code would lead to a line break in displayed text as well, instead of needing to add an empty line.<br />
<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:33, 15 October 2020 (UTC) G3ro<br />
<br />
:::OK, now I understand. I agree that splitting different topics usually improves legibility, but they should be split into separate paragraphs and not just by line breaks (e.g. using the &lt;br> tags). Paragraphs are semantic units whereas line breaks inside a paragraph are usually typographic errors.<br />
:::Also note that such splitting alone may not be enough to improve the text flow. For example, if we consider the intro for [[Wayland]], the second sentence about XWayland would not constitute a good paragraph - it is just a plain statement and the new topic is not nicely introduced. Ideally, you'd split the topic and make some wording changes for the second paragraph.<br />
:::As for the margin options, that is the difference between paragraph splitting and non-semantic line breaks. In my opinion, the styling is correct in this respect, as paragraphs should be discernible. You mentioned that you like line breaks to easily recognize where a sentence ends - but reading should be based on whole paragraphs, not sentences. There should be no reason to skip anything in the middle of a paragraph, otherwise it should be probably split into multiple paragraphs or otherwise rephrased.<br />
:::If you find it hard to follow a long sentence horizontally on a wide screen, we might consider enforcing some maximum width for the whole content. I think the readability would be better, since there would be more top-to-bottom eye movement at the cost of left-to-right-and-back.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:59, 15 October 2020 (UTC)<br />
<br />
== Xorg parentheses ==<br />
<br />
I actually think that X(org) is very useful to imply that it is one and the same thing.<br />
<br />
It might even be more confusing now, as we use both Xorg and X, because the wiki title and the package titles are Xorg.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:30, 17 October 2020 (UTC) G3ro<br />
<br />
:Well the conventions should be established on the [[Xorg]] page, not anywhere else... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:36, 17 October 2020 (UTC)<br />
<br />
:: Imo the conventions are established by upstream and they use a wide variety of X, X.org, X(org), Xorg etc.<br />
:: As I said I always prefer X(org) because then it is clear, that both are same thing.<br />
:: But ultimately it's your decision. <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:43, 17 October 2020 (UTC) G3ro<br />
<br />
:::When upstream is not capable of making a unambiguous decision, it makes sense that other projects pick some option and stick with it wherever they can to keep at least some consistency. So for this wiki, pages should use the same style as the [[Xorg]] page. But feel free to start a discussion about this in [[Talk:Xorg]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:56, 17 October 2020 (UTC)<br />
<br />
== SSHFS - systemd edit ==<br />
<br />
The edit was removed because "there is no advantage over using fstab entries".<br />
<br />
Is not only about the dis/advantages of the systemd option, is about that it is another possibility to achieve the task, that is why it was created in another level and the fstab section was left alone.<br />
<br />
Reconsider the edit as it presents another option which people can use.<br />
<br />
[[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 16:22, 22 October 2020 (UTC)<br />
<br />
:There is no need to use anything else, fstab just works well enough. Configuring mounts with systemd services is not a good idea - it is much more bloated than fstab and not the right tool for it. If anything, a different type of systemd units should be used: {{man|5|systemd.mount}}. But creating the mount units manually is still pretty useless since everything can be configured in fstab and systemd will generate the unit for you. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:22, 22 October 2020 (UTC)<br />
<br />
:: It is about the ability to use the user's .config file and all the proper options that are saved there. Also systemd gives the possibility to use different targets, so the user could mount it when an specific user logs in or when a graphical session starts. I could argue that bad a modification of fstab could lead to a system that doesnt boot, but such poorly configured systemd unit file just fails and the system is fine. Just give the user the information and let it decide what they can use depending on their use case. [[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 08:08, 24 October 2020 (UTC)<br />
<br />
:::You can configure systemd targets in fstab using the {{ic|x-systemd.wanted-by}} and {{ic|x-systemd.required-by}} options, there are also {{ic|nofail}} and {{ic|noauto}} options. Please read the {{man|5|systemd.mount}} manual.<br />
:::Using hosts from the user's {{ic|.ssh/config}} is the only thing which is not possible with fstab, but this does not warrant using the wrong tool for the task. Simple copy the full {{ic|user@hostname}} into fstab and you're done.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:47, 24 October 2020 (UTC)<br />
<br />
== [[Self-encrypting drives]] ==<br />
<br />
Hi, I'd like to respectfully disagree with the rollback. It's specific to sedutil that with most commands you need to input /dev/nvme0 (when encrypting the device) but for the sleep commands it requires /dev/nvme0n1 or it fails with a very unspecific error (Error saving the password to the kernel errno = 25), as found out in the discussion https://github.com/Drive-Trust-Alliance/sedutil/issues/90<br />
<br />
All in all I believe that it is important to keep this piece of information which was found out in a long discussion between the reporter and the developers. I ran into it and I believe many people may run into it, considering most of the new SSD will be NVMe. Best, [[User:Przemub|Przemub]] ([[User talk:Przemub|talk]]) 13:34, 28 October 2020 (UTC)<br />
<br />
:OK, then it makes sense. But it should be probably explained before, not in the section about the sleep command. Also please add the link to the note as a reference. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:27, 28 October 2020 (UTC)<br />
<br />
== Nvidia Installation ==<br />
<br />
The whole guide is unnecessary long and overcomplicated formulated.<br />
Shorter is better, most people will know their graphic card for example, so the determination etc. is only optional.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:21, 10 November 2020 (UTC) G3ro<br />
<br />
:Moving some info to some other page and leaving a tip behind does not make it shorter, but harder to follow. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:36, 10 November 2020 (UTC)<br />
<br />
== Btrfs layout ==<br />
<br />
Hi, Lahwaacz<br />
<br />
Thanks for maintaining [[Snapper]]! However I think the layout is not openSUSE specific and beneficial to all btrfs users. Can you elaborate your reason of undoing the edits? IMO the previous 'simple layout' complicates the rollback procedure.<br />
<br />
Cheers,<br />
[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 07:26, 3 December 2020 (UTC)<br />
<br />
:It is not overcomplicated, it is just doing things right. You can read about that in the forum thread, see the first note in [[Snapper#Suggested filesystem layout]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:24, 3 December 2020 (UTC)<br />
<br />
::Anyway I've moved the guides to my user page. It's not that I haven't read the 5-year-old forum post, it's that before the current layout I followed that post and resulted in a not fully rolled-back system. That post also sourced (then current) information from openSUSE. openSUSE has since massively overhauled the layout, as I pointed out in an edit you undid earlier.[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 09:02, 3 December 2020 (UTC)<br />
<br />
::Since last message I've extensively documented the new layout at [[User:I2Oc9/Btrfs_subvolumes]] and [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption]]. Have a look for yourself. Nothing new really, but IMO [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my take]] is much more simpler and complete than the supposedly [[Snapper#Restoring_/_to_a_previous_snapshot_of_@|simpler one]]. That one does not leverage native {{ic|snapper rollback}} or {{Pkg|grub-btrfs}}, among other things. I strongly suggest you try if you have time. [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 11:55, 3 December 2020 (UTC)<br />
<br />
::Actually if you look closely, none of [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my recovery methods]] is specific to [[User:I2Oc9/Btrfs_subvolumes#A_new_kind_of_layout|the new 'complex' layout]], it will work totally fine with the old one. I just don't think moving @ around in live environment is appropriate.<br />
<br />
::On the other hand, the layout recommendation has been updated by openSUSE [https://en.opensuse.org/SDB:BTRFS], why stick with the old one? [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 12:37, 3 December 2020 (UTC)<br />
<br />
:::The main reasons why I reverted your edits on the [[Snapper]] page are: 1) it was a huge change which was not discussed previously as required by [[ArchWiki:Contributing#The 3 fundamental rules]], and 2) it has some elements which do not apply to Arch (see below). If you wish to propose a better layout of the subvolumes, it should be discussed in [[Talk:Snapper]] first. Your user pages would serve as great drafts.<br />
:::Note that the current suggested layout is not ''flat'' in the sense of [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|your section]] - it has a separate subvolume for {{ic|.snapshots}} so it does not lead to the recursive mess. So your proposed layout seemed very similar to the current suggested layout. The real difference is which subvolume gets mounted at {{ic|/}}, but I did not find it explained anywhere on the Snapper page before I reverted the changes (I get it now from your user page). I also did not find a proper documentation of the openSUSE's layout - it seems to be just the product of their installer and the documentation only deals with the result, saying at most that [https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-snapper.html#sec-snapper-snapshot-boot the subvolume configuration must not be changed] for rollbacks to work.<br />
:::Now the openSUSE-specific elements: some Arch packages actually install software into {{ic|/opt}}, so the recommended layout should not suggest a separate subvolume for this path. Even more importantly, the pacman database is located at {{ic|/var/lib/pacman/local/}} and it must be rolled back along with the system, so there should be no separate subvolume for {{ic|/var}}. Instead, users should be encouraged to create (even nested) subvolumes for specific data directories under {{ic|/var}}, such as {{ic|/var/log}}, {{ic|/var/tmp}}, {{ic|/var/cache/pacman}}, {{ic|/var/lib/machines}}, etc.<br />
:::Finally, the suggested layout should not be GRUB-specific, there should be no recommendations regarding a boot loader. Sure it is useful to include non-trivial tips, but people may actually use a different boot loader.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:31, 4 December 2020 (UTC)<br />
<br />
::::Thanks for your detailed reply. I admit that I'm not knowledgeable on the intricate differences between distributions and shouldn't have made the changes without properly discussing them first.<br />
::::Yes, I get that the current layout is not [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|the one described in this section]] and indeed properly separates {{ic|/.snapshot}} and {{ic|/}}. The layout I proposed attempts to add some "niceties" such as supporting multi-distribution installations (complex and unnecessary, I agree) and bring the openSUSE layout here, which is a mistake, as you've pointed out.<br />
::::As for GRUB, since I use LUKS all the time and it's the only bootloader supporting encrypted {{ic|/boot}} on Btrfs on LUKS1, I really didn't think of any other possibilities.<br />
::::I will incorporate your recommendations to my user page and add a new section in [[Talk:Snapper]] pointing to those pages.<br />
::::Cheers -- [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:09, 4 December 2020 (UTC)<br />
<br />
:::::I've adopted [[Install_Arch_Linux_on_ZFS#System_datasets|Archlinux Root on ZFS layout]] to [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Create_subvolumes|my proposal]]. [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:56, 4 December 2020 (UTC)<br />
<br />
== Reflector Revert ==<br />
<br />
Hi Lahwaacz, about your [https://wiki.archlinux.org/index.php?title=Reflector&oldid=643749 revert], it seems like there's precedence for including AUR packages that replicate the code on the wiki. For example, in [[dash#Relinking /bin/sh]].<br />
<br />
In addition, I believe that there's value for linking the AUR package because it allows a simpler user experience where the AUR package is maintained for them. That way, if it is ever updated, they can easily fetch the update instead of religiously checking the wiki page (which most users probably don't do).<br />
<br />
Thanks!<br />
<br />
[[User:Denton-l|Denton-l]] ([[User talk:Denton-l|talk]]) 01:52, 7 December 2020 (UTC)<br />
<br />
:That precedence was only created by [https://wiki.archlinux.org/index.php?title=Dash&type=revision&diff=561587&oldid=518398 yourself]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 5 May 2021 (UTC)<br />
<br />
== firefox zoom ==<br />
<br />
"no reason to zoom manually, see HiDPI)" - fractional scaling doesn't work [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 26 December 2020 (UTC)<br />
<br />
:That should be explained in [[HiDPI#Firefox]] anyway. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:48, 26 December 2020 (UTC)<br />
<br />
::it's good to have this mentioned somewhere clearly so people know about it before they say "fonts on linux suck" [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 15:51, 29 December 2020 (UTC)<br />
<br />
== Intel GVT-g edits ==<br />
<br />
Hello Lahwaacz,<br />
<br />
I have noticed that you reverted one of the edits I have performed on [[Intel_GVT-g]].<br />
<br />
About this revert: [https://wiki.archlinux.org/index.php?title=Intel_GVT-g&oldid=648062 Windows problems are out of scope]<br />
<br />
While I understand that the ArchWiki is about ArchLinux, this article in particular mentions Windows in the introduction, and already includes another troubleshooting point about Windows. The issue I have encountered with the black bars is somewhat common, as I have found other people discussing it online, and I really fail to see why not including this piece of information in this article would be better than including it.<br />
<br />
Please, let me know your thoughts. If you think that the point can be improved, I will be happy to do that.<br />
<br />
Ciao,<br />
<br />
[[User:Wilcomir|Wilcomir]] ([[User talk:Wilcomir|talk]]) 09:14, 3 January 2021 (UTC)<br />
<br />
:Well, the existing section about a Windows problem is actually solved by configuring the Linux host. I think anything involving configuration or installation of programs in Windows is not appropriate for long troubleshooting sections. At most, they could be mentioned in a short reference to other sites which describe the problem in detail. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:34, 3 January 2021 (UTC)<br />
<br />
== <s>XDG configuration for Vim</s> ==<br />
<br />
Hi Lahwaacz,<br />
<br />
You have reverted the updated Notes for Vim on [[XDG Base Directory]], because "copy-pasted from a blog post".<br />
<br />
The problem is, not only is the configuration presented currently also copied from a blog post too, but is already 10 years old.<br />
<br />
Would it be OK, if we bring back the more up to date version? Or at least remove the obsolete one and leave link to newer?<br><br />
(Although I think a copy on wiki would be beneficial in case my blog ceases to exist)<br />
<br />
[[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 02:05, 12 January 2021 (UTC)<br />
<br />
:OK let's close this. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:49, 29 August 2021 (UTC)<br />
<br />
== Root on ZFS draft ==<br />
<br />
Hi, I submitted [https://github.com/openzfs/openzfs-docs/pull/104 a Root on ZFS draft] to official doc repo.<br />
<br />
In the draft, the following directories are separated from root filesystem:<br />
home,root,srv,usr/local,var/log,var/spool,var/tmp<br />
<br />
Is this appropriate for Arch Linux? Or do you have any suggestion on the draft?<br />
Any comment is appreciated.<br />
[[User:M0p|M0p]] ([[User talk:M0p|talk]]) 01:28, 23 January 2021 (UTC)<br />
<br />
== Re: undo GRUB - Common installation errors ==<br />
<br />
Concerning your undo of [https://wiki.archlinux.org/index.php?title=GRUB&diff=next&oldid=649799 Add the error message `Could not prepare Boot variable: No space left on device`)]<br />
Is there a better place to for this Information? One can find the solution in various forums, but I thought it could be helpful to have it in this wiki somewhere. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 12:51, 25 January 2021 (UTC)<br />
<br />
:The error message is not specific to the {{ic|/sys/fs/pstore/}} filesystem (which does not even seem to be used by default on Arch...) Where did you find that? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:16, 25 January 2021 (UTC)<br />
<br />
::I did not find anything Arch specific, but this post about Debian helped: [https://donjajo.com/fix-grub-efibootmgr-not-set-variable-no-space-left-device/ Post]. I also found something about [https://askubuntu.com/questions/1072618/could-not-prepare-boot-variable-no-space-left-on-device-grub-install-error-ef /sys/fs/efi/efivars/dump-*] The problem is that the actual efi-partition does not seam to be the problem, there is more than 70% space left. If there is better information to guide the user in the right direction that wuld be more helpful. This is what I found worked, but I admit that I don't know much about how grub operates. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 16:20, 25 January 2021 (UTC)<br />
<br />
:::This wiki ''is'' Arch specific so old posts about Debian or Ubuntu do not apply. Even if they did, this is hardly a ''common'' installation problem. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:29, 26 January 2021 (UTC)<br />
<br />
::::I know that, and would not have put it there if it didn't occur on my Arch Linux installation. If this is something that should not be documented in this wiki, I understand that. Is there any other place you would recommend? An issue for grub-install maybe? [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 22:24, 26 January 2021 (UTC)<br />
<br />
== Kernel Compilation time ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Kernel&diff=next&oldid=650896 link]<br />
<br />
I don't think we should judge information by what is obvious to experts.<br />
People might have experience with compilation of other programs, which mostly is fast, and then there is the kernel which takes forever to compile.<br />
I think it does not hurt anyone to make people aware of it.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:03, 6 February 2021 (UTC)<br />
<br />
:It is an unnecessary information without a definite answer which can even be [https://html.duckduckgo.com/html?q=how%20long%20does%20it%20take%20to%20compile%20Linux%20kernel searched elsewhere]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:23, 6 February 2021 (UTC)<br />
<br />
:: I disagree, with that argument nearly any tip and note is unnecessary. These things are intended to inform users about things that should be taken into consideration and that are different from the norm.<br />
:: Also do you search for the compilation time for every program you intend to compile? I don't.<br />
:: Furthermore this info is included, why not tell it to people directly on the start, so they don't read over it? <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:36, 6 February 2021 (UTC)<br />
<br />
:::If someone wants to compile the Linux kernel, they should obviously expect that it will take ''some time''. Stating that it "can take up to several hours" does not make sense without referring to a specific hardware. Obviously, it will take much longer on a poor laptop than on a powerful workstation with a many-core processor, but people can assume that themselves. Without a reference to a specific hardware, the note is unnecessarily discouraging because the compilation can be as fast as some tens of minutes - it is by far not the most expensive package to compile...<br />
:::As you said, people can find better notes later along with advices to enable parallel build etc. which is all that's needed IMO.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:03, 6 February 2021 (UTC)<br />
<br />
== Wayland style ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Wayland&diff=prev&oldid=650979 link]<br />
<br />
I think in the old version it was much easier to read the "source code", so I don't see why there can't be spaces between it.<br />
Things shouldn't be complicated more than necessary.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:11, 6 February 2021 (UTC)<br />
<br />
:Most templates on the wiki are written without spaces around the |. When we [https://github.com/archlinux/archwiki/pull/32 switch the editor], there will even be syntax highlighting. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:25, 6 February 2021 (UTC)<br />
<br />
== Bluetooth keyboard ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php/Bluetooth_keyboard link]<br />
<br />
On your last change you said "not specific to keyboards, all of this is already mentioned on the Bluetooth page", the point is that this is extremely relevant for bluetooth keyboard since it is required to perform the login! If this little piece cannot be duplicated I would suggest at least to leave a link saying "If you want to autoconnect at boot please refer to...". I'm new here and I would not touch it further, but please evaluate the suggestion (this is because after reading bluetooth keyboard page and not finding the solution I had to look for it on forums)<br />
<br />
{{unsigned|21:17, 20 February 2021|Stevexyz}}<br />
<br />
:Well, basically the whole page is flagged to be merged with the main [[Bluetooth]] page, so it's expected to be incomplete. Other tips may always be found on a more general page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:40, 21 February 2021 (UTC)<br />
<br />
== Re: Steam Needs to be online error ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Steam/Troubleshooting&diff=next&oldid=653073 link]<br />
<br />
The problem here is that DNS resolution in general works already (yes even outside browsers), i.e. <br />
<br />
dig media.steampowered.com<br />
<br />
would run successfully, but the Steam client couldn’t resolve it. The DNS request from 'dig' shows up in my nameserver’s log, the one Steam should send doesn’t. This indicates it might indeed a problem specific to Steam, and it’s not as easy as just say "go fix your DNS resolution", as it already may work correctly for everything but Steam.<br />
<br />
Additionally, at no point does [[Domain name resolution]] even mention nscd, so you effectively removed a fix/workaround for the problem from the Wiki. So I was definitely not "duplicating an article" here. [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 08:12, 22 February 2021 (UTC)<br />
<br />
:Could I please hear your opinion on this? I’d be happy to just add something along the lines of "if you made sure DNS resolution works but Steam still can’t resolve it, try additionally enabling the nscd service" to the Steam troubleshooting page. Unfortounately I don’t know why running the service helps, but I’d still like to give others an easier time finding this solution than I had myself. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 09:15, 28 February 2021 (UTC)<br />
<br />
::Hi, I'm sorry for the delay. Could you test if using a different program for DNS caching (e.g. [[systemd-resolved]]) instead of {{ic|nscd.service}} fixes the problem? If not, then it's probably not due to DNS - {{man|8|nscd}} actually caches more than just DNS. Also if you have a reference to some website where you found about nscd, it would be nice to add it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 28 February 2021 (UTC)<br />
<br />
:::No worries. Using [[systemd-resolved]] for DNS resolution (and caching I guess, I wasn’t aware it does that, too) was a thing I did try, but that didn’t fix it for me. The place I found out about nscd fixing it was actually the [https://bbs.archlinux.org/viewtopic.php?id=263356 Arch forums]. When I search the web for Steam in combination with nscd, all I can seem to find are more forum entries of people that don’t know why that fixes it either. I can try a bit to find out what nscd does to make it work, but I’m not too confident I will be successful. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 14:51, 28 February 2021 (UTC)<br />
<br />
::::Okay, so {{ic|nscd}} allows to [https://man7.org/linux/man-pages/man5/nscd.conf.5.html dis-/enable caching per service], and it’s indeed enabling it for {{ic|hosts}} that makes it work. That’s weird though, since [[systemd-resolved]] has caching enabled by default, and using it for resolution didn’t make {{ic|steam}} work for me. Leads me to think that I didn’t set it up correctly, although resolving via {{ic|dig}} *did* work. Since [[steam]] depends on [[Name Service Switch]], I tried resolving using {{ic|getent}} manually with nscd disabled, but that worked while steam did not. I’m not really sure what to make of this, since I have no idea how this low level networking/resolving stuff works really. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 15:39, 28 February 2021 (UTC)<br />
<br />
:::::Hmm, I don't know the details either. Steam needs the multilib packages so maybe that's part of the problem. Could you add your findings to the section and use [[Template:Expansion]] for the missing details? Maybe someone can figure it out. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:44, 28 February 2021 (UTC)<br />
<br />
::::::Sure, I can do that. I’ll probably need a minute to figure out how to use the template though, but I should have the time later today. Thanks for your input on this. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 17:56, 28 February 2021 (UTC)<br />
<br />
== Removal of website link ==<br />
<br />
Refers to this: https://wiki.archlinux.org/index.php?title=PipeWire&diff=next&oldid=653701<br />
<br />
I don't understand why that has to be removed. The official website should be always worth a mention, even if it is somehow mentioned in the text already.<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:02, 28 February 2021 (UTC)<br />
<br />
:The "See also" section is for additional links, it is not intended as a collection of all links used on a page. Adding links which are clearly mentioned in the appropriate place only clutters the list. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:24, 28 February 2021 (UTC)<br />
<br />
:: There are just three links and only one of them is really useful, the others could maybe even be removed as they link to old blog posts.<br />
:: I can only repeat myself, that things don't always have to be made more complicated than necessary.<br />
:: The official website is a central point which links to many more useful ressources, so it's one link for much information.<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:34, 28 February 2021 (UTC)<br />
<br />
== Removal of bootia32.efi generation procedure from X205TA install page. ==<br />
<br />
Those [https://wiki.archlinux.org/index.php?title=ASUS_x205ta&diff=596239&oldid=562734 instructions] were really straightforward and useful, imho in comparison present ones require too much material to be confident with. I think it's (paradoxically) way easier to generate the file than to configure a `grub.cfg` from zero to boot a live cd. Can we undo the edit? Otherwise we could put them in a new page or section in the GRUB page and link to them maybe. [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 05:07, 4 March 2021 (UTC)<br />
<br />
:If there is something wrong with the information on the [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Booting_64-bit_kernel_on_32-bit_UEFI general page], it should be improved instead of describing the same procedure in a different way on a completely unrelated page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:16, 6 March 2021 (UTC)<br />
<br />
:: I didn't know we had that info in the UEFI article. I think it could be appropriate to insert the [https://en.wikipedia.org/wiki/Template:See_also#Examples See also] archwiki equivalent (which I couldn't find) for UEFI page on top of the aforementioned section, what do you think? [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 13:28, 7 March 2021 (UTC)<br />
<br />
:::Well, the removed section was previously flagged with "Duplicates [[Unified Extensible Firmware Interface#Booting 64-bit kernel on 32-bit UEFI]]"...<br />
:::Also the laptops pages are usually related to most of the general pages on this wiki, adding all of them would be pretty useless. Users should not expect to find everything on a single laptop page, they should always check if there is a general page for their topic with more details.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:58, 7 March 2021 (UTC)<br />
<br />
== Re: Show how to use systemd/Timers with wg-quick@.service ==<br />
<br />
I don't think using service is the appropriate when you want to start Wireguard at boot. For most people connecting to a VPN is not exactly part system startup.<br />
A timer should more appropriate.<br />
[[User:ENV25|ENV25]] ([[User talk:ENV25|talk]]) 10:03, 11 April 2021 (UTC)<br />
<br />
:I don't see how OnBootSec=1min is more appropriate than an automatically starting service. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:19, 11 April 2021 (UTC)<br />
<br />
== USB flash installation medium (BIOS bootable) ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=next&oldid=673926 revert]: "making the partition bootable is discussed below"<br />
Do you mean installing syslinux and `dd` the [gpt]mbr with "discussed below"? This was not enought for my setup (Sandisk Ultra 64GB, Dell XPS 9370) to make the partition BIOS bootable. It did work right after I checked "Legacy BIOS Bootable" checkbox using gnome-disks.<br />
<br />
{{Unsigned|13:42, 30 May 2021 (UTC)|Auipga}}<br />
<br />
:Yes, that's what I meant. If it does not work, it should be fixed rather than providing a duplicate instruction without a reason. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:16, 30 May 2021 (UTC)<br />
<br />
== Systemd-networkd systemd-networkd-wait-online.service discussion modifications ==<br />
<br />
I'm not sure why you're reverting my edits.<br />
<br />
You said: "''empty ExecStart is explained in Systemd#Examples''"<br />
<br />
Exactly: Systemd#Examples clearly states "''As another example, in order to replace the ExecStart directive for a unit that is '''not of type oneshot'''''"<br />
<br />
'''systemd-networkd-wait-online''' is a oneshot service. By having the superfluous empty ExecStart you're just confusing people.<br />
<br />
Regarding the file naming, yes the name is irrelevant, but it's generally helpful to non-expert users to stick to canonical naming conventions.<br />
<br />
Please make sure you're on solid ground before reverting edits; you're just discouraging people from engaging with the Wiki. Thanks. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 16:51, 9 June 2021 (UTC)<br />
<br />
:{{man|5|systemd.service}} says: "Unless Type= is oneshot, exactly one command must be given. When Type=oneshot is used, zero or more commands may be specified."<br />
:So when a service is not oneshot, users ''must'' clear ExecStart before adding a modified command in the drop-in file. If a service is oneshot, they ''may or may not'' clear ExecStart, since the service may have multiple ExecStart commands.<br />
:In case of systemd-networkd-wait-online, I don't see why you would want to run multiple instances with different options: one to wait for ''all'' links (which is the default command) and another one to wait for ''any'' link (which is the command in the drop-in example). So clearing ExecStart really makes sense for systemd-networkd-wait-online.<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:44, 9 June 2021 (UTC)<br />
<br />
== Pacman: Install missing dependencies ==<br />
<br />
Hi. [https://wiki.archlinux.org/index.php?title=Pacman&type=revision&diff=690774&oldid=690762 "Pacman" Revision as of 21:50, 4 August 2021 (undo)] - maybe at least put that into [[System_maintenance#Avoid_certain_pacman_commands]]?<br />
<br />
[[User:Galeksandrp|Galeksandrp]] ([[User talk:Galeksandrp|talk]])<br />
<br />
:[[System_maintenance#Avoid_certain_pacman_commands]] already mentions {{ic|-Rdd}}. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:12, 14 August 2021 (UTC)<br />
<br />
== DPMS: "\033[9;0]" ==<br />
<br />
Hi. It seems that you removed {{ic|echo -ne "\033[9;0]"}} from [[Display Power Management Signaling|DPMS]]<br />
<br />
https://wiki.archlinux.org/index.php?title=Display_Power_Management_Signaling&diff=629705&oldid=625073<br />
<br />
[https://www.denx.de/wiki/view/DULG/SwitchOffScreenSaverAndBlinkingCursor A DULG page] and [https://unix.stackexchange.com/a/23636 a U&L post] brought me here.<br />
<br />
May I ask (1) if this method is still working; and (2) where is this escape sequence documented? [not found in {{man|4|console_codes}}]<br />
<br />
Thanks.<br />
<br />
{{Unsigned|05:23, 15 August 2021 (UTC)|PXf}}<br />
<br />
:[[Display Power Management Signaling#DPMS interaction in a Linux console with setterm]] says that setterm works by writing escape codes to the terminal device. The first subsection shows how to reverse-engineer the escape codes. Note that the escape codes are an implementation detail that users should not be concerned with, their documentation is certainly not our job. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:40, 15 August 2021 (UTC)<br />
<br />
== Linux console/Keyboard configuration ==<br />
<br />
Hi, you recently reverted my edit https://wiki.archlinux.org/index.php?title=Linux_console/Keyboard_configuration&oldid=693887. The reason I made that edit, was that I used to put my custom keymap in {{ic|/usr/local/share/kbd/keymaps/personal}} per the previous version of the wiki page. But this doesn't work with ''sd-vconsole'', as it's include files don't get loaded. Your suggested workaround by adding all required files using [[mkinitcpio#BINARIES and FILES|mkinitcpio BINARIES and FILES]] is rather tedious, as all the include files need to be in there, added by hand. This is done automatically by ''sd-vconsole'' if the file was put in {{ic|/usr/share/kbd/keymaps/}}. The reason I made this edit is due to https://bugs.archlinux.org/task/71788. See Giancarlo Razzolini's comment. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:43, 2 September 2021 (UTC)<br />
<br />
:It's just one custom file under {{ic|/usr/local}} and one entry in {{ic|FILES}}. What is so tedious about it? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:37, 2 September 2021 (UTC)<br />
<br />
:: It's not just one file. All the dependencies need to be included too under {{ic|/usr/share/kbd/keymaps/}}. There are quite a few in my case, when I just include ''us.map'' to modify it slightly. See the ''sd-vconsole'' hook script. That script has a part where it finds all the dependencies of a keymap.<br />
<br />
:: * ''/usr/share/kbd/keymaps/i386/include/compose.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/euro1.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-keys-bare.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-with-alt-and-altgr.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/qwerty-layout.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/personal.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/us.map''<br />
:: * ''/usr/share/kbd/keymaps/include/compose.latin1''<br />
<br />
:: [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 12:01, 2 September 2021 (UTC)<br />
<br />
::: I moved this to the talk page so I remember it and others can discuss too. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:18, 4 September 2021 (UTC)<br />
<br />
::: Oh, I see. In that case I suggest we add a tip like this:<br />
::: {{Tip|If you use the {{ic|sd-vconsole}} [[mkinitcpio#Common hooks|mkinitcpio hook]] instead of {{ic|keymap}}, keymaps located under {{ic|/usr/local}} as well as their dependencies from {{ic|/usr/share/kbd/keymaps}} need to be manually specified in the {{ic|FILES}} array in {{ic|mkinitcpio.conf}}. On the other hand, custom files located in {{ic|/usr/share/kbd/keymaps}} will be added automatically when configured in {{ic|/etc/vconsole.conf}}.}}<br />
::: Because this is relevant only for people using the {{ic|sd-vconsole}} hook and otherwise it does not make sense to pollute {{ic|/usr/share/kbd/keymaps}} with custom files.<br />
::: — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:55, 5 September 2021 (UTC)<br />
<br />
== cow_* ==<br />
<br />
Hi Lahwaacz. About the [https://wiki.archlinux.org/index.php?title=Archiso&diff=next&oldid=692981 how/why issue] (there will be no more &lt;!-- --&gt;). What if, for once, that I want to install some large packages after booting archiso, and would not bother modifying packages.x86_64 and building again? [https://www.memesmonkey.com/topic/works+on+my+machine <s>''on my machine''</s>] Darren "Un1Gfn" "[[User:PXf|PXf]]" Ng ([[User talk:PXf|talk]]) 08:18, 12 October 2021 (UTC)<br />
<br />
:It is a subsection of "Tips and tricks", not "Troubleshooting", so it should start with a clear motivation saying ''why'' the tip is useful, rather than an error message that the user has no idea if they will face or not. If you have such description, feel free to rewrite the section. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 05:42, 13 October 2021 (UTC)<br />
<br />
::What about making it a subsection of "[[Archiso#Troubleshooting|Troubleshooting]]" and renaming it to {{ic|partition / too full}}? [[User:PXf|PXf]] ([[User talk:PXf|talk]]) 06:45, 13 October 2021 (UTC)<br />
<br />
:::It's better to motivate it as a tip/trick rather than solve the problem after it happens. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:48, 13 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
(Undo revision 699881 by Oliver (talk) - installing arch-install-scripts does not get the image to "the same footing" as the archiso, even installing something for the first time is not an excuse to violate Help:Style#Package management instructions)<br />
<br />
'the same footing' may be poor choice of wording maybe but it's also not false. You are in a SIMILAR place, not 'exactly identical to the dot' e.g. same footing<br />
<br />
but 'installing something for the first time' is NOT what is going on here really. If we quote the style guide:<br />
<br />
''every Arch user should know pacman's article by memory''<br />
<br />
<br />
The thing is, this is NOT an Arch user yet. They have no idea what's going on, how to do stuff and just want to get started and installed. You can't expect _new_ not-yet-a user, to figure out everything in a daunting installation; by being a smart-bum about it. Yes, the style guide is completely correct on all other points. But I would think that this is the exception, rather then the rule. Help your new users a little. Introduce them gentle with open arms. From a 'first UX kind of way, this is horrible to treat your potentially new users.<br />
<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 17:40, 26 October 2021 (UTC)<br />
<br />
:We use the same convention on the [[Installation guide]] itself. They should read the [[pacman]] page to learn how to install packages as soon as possible, so why not right when they use it for the first time? There is a gentle link to "[[install]]" before the package name, so the clueless user will follow the link and learn something. They will not learn anything by copy-pasting a quick one-liner. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 26 October 2021 (UTC)<br />
<br />
Yes, you ARE right, however; this is the install guide (relatively speaking) Let them install the system first with a gentle nudge; THEN force them to learn stuff :p<br />
<br />
Again, I understand the policy and the reasoning behind it very much so; but it's those first few steps that are the hardest. It's birds vs humans I suppose; birds throw their children out of their nests to teach them to fly (or die); Humans raise their children first in a more gentle manor. Is arch really the 'l337 fly or die, rtfm n00b' kind of distro?<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 18:25, 26 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
skip the rsync protocol<br />
<br />
As per my 'commit message' The user is confronted with the following:<br />
WARNING: failed to rate rsync download (rsync://mirror.erickochen.nl/archlinux/community/os/x86_64/community.db): [Errno 2] No such file or directory: 'rsync'<br />
<br />
You really think we should not reflect this in the documentation for now, until this dependency is actually properly resolved in the package? (could be weeks?)<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 18:32, 26 October 2021 (UTC)</div>Oliverhttps://wiki.archlinux.org/index.php?title=User_talk:Lahwaacz&diff=700020User talk:Lahwaacz2021-10-26T18:31:53Z<p>Oliver: /* Install Arch Linux via Docker */ typo</p>
<hr />
<div>== bot checking links after move ==<br />
<br />
Hi, re [[Talk:Touchpad Synaptics#adding libinput alternative]]. [[Touchpad Synaptics]] has 100+ backlinks and the more important ones - a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of [[Touchpad Synaptics]] and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:36, 26 September 2015 (UTC)<br />
<br />
:Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a [[UUID]] page, which was later generalized and renamed to [[Persistent block device naming]] and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace <nowiki>[[pacman|Install]]</nowiki> with <nowiki>[[Install]]</nowiki> etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:01, 26 September 2015 (UTC)<br />
<br />
::Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [https://wiki.archlinux.org/index.php/Special:WhatLinksHere/Beginners'_Guide]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:02, 26 September 2015 (UTC)<br />
<br />
== mkosi ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=Systemd-nspawn&diff=0&oldid=491975 revert]: You can use mkosi also to create a container/directory tree (-t directory). So it can do the same and more. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 11:33, 1 October 2017 (UTC)<br />
<br />
:Alright, how is the "more" relevant to systemd-nspawn though? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:30, 3 October 2017 (UTC)<br />
<br />
::Hi, mkosi let's you create images (or directory trees) of various different distributions and allows you to do things like setting the root-password or installing additional packages. systemd-nspawn alows you to boot such images/directory trees. So I thought mentioning mkosi as alternative to manually creating a container with pacstrap or debootstrap would be worth it. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 22:23, 5 October 2017 (UTC)<br />
<br />
== Waking from suspend with USB device ==<br />
<br />
Hi Lahwaacz, thanks for your input on this topic.<br />
Can you help me a bit further, I know the USB host controller and the USB device are different things but I thought that enabling the host controller was not necessary anymore, see [https://www.spinics.net/lists/linux-usb/msg53661.html].<br />
In my case all the {{ic|driver/*/power/wakeup}} are all enabled by default and the {{ic|/proc/acpi/wakeup}} as well.<br />
Anyway I have added a step in my explanations to identify the path awaiting for more clarity.<br />
<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 21:57, 16 January 2018 (UTC)<br />
<br />
:Hi, thanks for the link, it's entirely possible that something changed since the section was written. However, in my case only the keyboard device has wakeup enabled by default: {{bc|<nowiki><br />
$ for f in /sys/bus/usb/drivers/usb/*/power/wakeup; do echo "$f: $(cat $f)"; done<br />
/sys/bus/usb/drivers/usb/1-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/2-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-11/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-12/power/wakeup: enabled<br />
/sys/bus/usb/drivers/usb/3-13/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-4/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb2/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb4/power/wakeup: disabled<br />
</nowiki>}}<br />
:But in practice it seems to wake up the system even without the host controllers enabled for wakeup... It might also depend on some BIOS/firmware settings but if it works by default on most systems then I think the host controller settings could be removed again.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:14, 19 January 2018 (UTC)<br />
<br />
== Are supported local/remote destinations important for choosing a backup program? ==<br />
<br />
You [[Special:Diff/525550|reverted]] my edit adding supported backup destinations to [[Synchronization_and_backup_programs]]. This is puzzling to me. Here are some thoughts:<br />
* if choosing any backup program, the ability to send the backup off-site vs only on a local disk is a key feature consideration. Perhaps *the* key feature: one helps me recover in case my house gets burglarized or burns down, and the other does not. This is a much more important feature consideration than, say, whether the program is written in Go or Mono (something that has a full column). I think it's hard to disagree on that.<br />
* Given this, I am very puzzled you would use the term "useless" in the revert message.<br />
* I assume you didn't like that the table got even bigger (it didn't fit into the layout even before). I don't like it either, but perhaps the revert should have said "can you put this somewhere else, not in this already-too-big table?"<br />
* On a personal note, when I provide feedback or give opinion on somebody else's work, I'd like to be constructive and kind, instead of aggressive and putting people down. Just a thought. Thanks for listening.<br />
<br />
[[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 17:38, 11 June 2018 (UTC)<br />
<br />
:No because you can use any remote back-end with any backup application by just running one command / writing the backups to a [[FUSE]] (if available).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:39, 12 June 2018 (UTC)<br />
<br />
::Hmm, by that reasoning we don't need the Arch package repository, as long as we have source code and makepkg. Or Perl, if we have bash and awk. But even then, and if all the fuse backends existed (I doubt they do), and if it were easy to set all of them up (another thing I doubt), do you indeed believe that running something written to read/write local files will be just as efficient backing up gigabytes of data to a remote repository as something that is specifically optimized for that use case? Note that backing up, say, daily, a typical hard drive via tpyical consumer broadband is still quite a bandwidth challenge in many places today. What about we add this info, and remove (or merge) some other columns to make the table smaller? {{Unsigned|18:08, 12 June 2018|Jernst}}<br />
<br />
:::Your comparisons don't make sense. Mind the slash in my response, you do not need a FUSE implementation, a simple CLI suffices. You do not need to "set all of them up", you only need one. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 18:47, 12 June 2018 (UTC)<br />
<br />
::::If you ever attempt to help a normal user set up a reliably-working off-site backup strategy, think of this discussion. In the meantime, this is all the time I'm going to spend on a discussion that has such repeated gems in it as "makes no sense" without explaining why you think so. Have a nice day. [[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 18:54, 12 June 2018 (UTC)<br />
<br />
== The pip section in [[Python package guidelines]] ==<br />
<br />
Hi, you wanted the warning about using pip or wheels restored but accidentally(?) reverted my whole set of changes. I redid them, leaving the warning in place. – [[User:Flying sheep|flying sheep]] 08:17, 8 March 2019 (UTC)<br />
<br />
:Full revert was intentional, because the "wheel" section is not a full replacement for "pip" because there are packages which don't provide wheel files. As I said in the edit summary, there is no reason to recommend one or the other due to the warning. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 8 March 2019 (UTC)<br />
::That still doesn’t explain why you reverted the first part, that had nothing to do with the pip/wheel section and simple improves the files.pythonhosted.org URLs. I restored that one while we’re discussing the pip/wheel section. And about that: There’s no reason to use pip for anything else, and pip is only used because some people (me included) didn’t understand that you can install most wheels by just extracting them to the correct location. So what do you think is missing from my wheels section that the former pip section had? – [[User:Flying_sheep|flying sheep]] 11:41, 11 March 2019 (UTC)<br />
<br />
:::If you didn't notice, the page includes "guidelines" in the title. So the page should contain only common and recommended ways to do things, not everything that is possible to do. If you think that your way to install "wheels" should be followed by everybody, feel free to discuss it on the talk page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:26, 11 March 2019 (UTC)<br />
::::Well, extracting static archives sounds much more recommended than running pip with like 7 options to make it behave. I added a talk item: [[Talk:Python package guidelines#Remove_pip_section_in_favor_of_wheels_section?]] – [[User:Flying_sheep|flying sheep]]<br />
<br />
== wpa_supplicant ==<br />
<br />
Regarding https://wiki.archlinux.org/index.php?title=WPA_supplicant&diff=577215&oldid=577167, one person ran into this problem in March of this year and spent too much time diagnosing it:<br />
<br />
https://bbs.archlinux.org/viewtopic.php?id=244950<br />
<br />
It took me a few days to find the problem. I want to make sure the next time someone encounters it, they easily find relevant information about what the cause is. Since you've reverted my edits to both netctl and wpa_supplicant, what do you suggest?<br />
<br />
--<br />
<br />
[[User:Pooryorick|Pooryorick]] ([[User talk:Pooryorick|talk]]) 08:24, 18 July 2019 (UTC)<br />
<br />
== F2FS and GRUB ==<br />
<br />
Hello. :) I'm here to address a recent disagreement. I noticed a reversion of my edit regarding the F2FS filesystem, in particular regarding the configuration file to edit (with you representing /boot/grub/grub.cfg and me representing /etc/default/grub). I run F2FS on my daily driver with an encrypted root filesystem and encrypted boot on a separate partition, and have never had to touch grub.cfg. I only automatically generate it. It's possible to use either, but /etc/default/grub would make more sense as a recommendation in my mind because grub.cfg has the potential to be overwritten during updates, whereas /etc/default/grub doesn't. <br />
<br />
If there's a compelling reason to use grub.cfg over /etc/default/grub, please let me know. ^^ I'm always eager to learn more about Arch. I don't want to get in a reversion war so I've left your change untouched for the time being.<br />
<br />
[[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 00:17, 8 September 2019 (UTC)<br />
<br />
:The reason is explained in the section: "If GRUB is used with an unsupported filesystem it is not able to extract the UUID of your drive so it uses classic non-persistent /dev/sdXx names instead." If it does not apply to F2FS, it should be made clear. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:29, 8 September 2019 (UTC)<br />
<br />
::You can specify UUID's in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, so my proposed solution would work for F2FS and other unsupported filesystems, without the burden of manually editing grub.cfg. If there's anything I need to clarify or something else I'm missing, just let me know. :) [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 19:37, 8 September 2019 (UTC)<br />
<br />
:::The {{ic|1=root=}} parameter is not supposed to be in GRUB_CMDLINE_LINUX_DEFAULT, regardless if UUID is used or not. ''grub-mkconfig'' automatically detects the root filesystem and adds the appropriate {{ic|1=root=}} parameter based on GRUB_DISABLE_LINUX_UUID. In any case, your change to the paragraph does not make sense. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:02, 8 September 2019 (UTC)<br />
<br />
::::It could simply be because I use full disk encryption, and adding a kernel parameter for the encrypted disk's UUID is correct in that situation. You're more experienced with contributing to the wiki, so I guess I'll defer to your judgment. It felt like a reasonable edit and solution to me and I don't see the downside to including it in GRUB_CMDLINE_LINUX_DEFAULT. [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 05:38, 9 September 2019 (UTC)<br />
<br />
== dracut executable link ==<br />
<br />
Hello, your last edit on the dracut page (https://wiki.archlinux.org/index.php?title=Dracut&oldid=596388) that undid my 'Link to direct "make executable" section for executable link' commit states: "the redirect executable points exactly to that section", but it doesn't. Following the [[executable]] link just points to the top of the Help:Reading page.<br />
<br />
{{unsigned|17:06, 28 January 2020|Krathalan}}<br />
<br />
:In that case your browser probably does not work correctly, because the redirect [https://wiki.archlinux.org/index.php?title=Executable&redirect=no really points to the section]. Or MediaWiki, there was a bug several years ago... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 28 January 2020 (UTC)<br />
<br />
:: How strange... thanks for pointing that out. It does indeed appear to be some issue with my Firefox configuration. [[User:Krathalan|Krathalan]] ([[User talk:Krathalan|talk]]) 19:51, 28 January 2020 (UTC)<br />
<br />
== Getting install.php work in DokuWiki ==<br />
<br />
Hi, than you for having undone my contribution and pointed to the right solution on [[Dokuwiki#Configuration]]. Indeed I had read this solution before, but I was misled by the condition "if you are using lighttpd or nginx and your PHP version is lower than 7": as I use Apache with php v. 7.4.3 I didn't take it into account. Do you know what a correct rephrasing could be? Maybe it should be deleted?<br />
<br />
Also, I think that, at the end of this same section, one should add something like "verify that {{Pkg|php-gd}} is installed and restart {{ic|php-fpm.service}}".<br />
<br />
Naturally I can do it myself, but I prefer to ask before.<br />
[[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 17:31, 19 February 2020 (UTC)<br />
<br />
:Hi, apparently it depends on whether you had {{ic|open_basedir}} set previously or not. I've changed the page, feel free to update the gd extension. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:16, 19 February 2020 (UTC)<br />
<br />
::Thank you! However, while, I didn't have {{ic|open_basedir}} set previously, I couldn't access ''install.php''. I suspect there is another thing to do, since the configuration editor in DokuWiki complains that it cannot modify the configuration files although ownership and permissions are correctly set for the relevant symlinks, directories and files, and so is {{ic|open_basedir}}. However I can edit my pages. Maybe a return from a new user with a fresh installation would be more useful, though. [[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 08:20, 20 February 2020 (UTC)<br />
<br />
== Dead link in Simple stateful firewall#See Also ==<br />
<br />
Hi, Jakub. I am about [https://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&diff=599725&oldid=599717 this] edit. I tried to follow that link one more time and it is not require entering captcha. I am not see any content limitations and my colleague (he uses Tor) does not see them too. I am not sure how it works, so I leave it on your descision. -- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 14:29, 1 March 2020 (UTC)<br />
<br />
:Well, maybe it depends on the location from which the request comes. But I don't know how it works either... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:33, 1 March 2020 (UTC)<br />
<br />
::my guess is it returns captcha for crawlers only -- [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 01:59, 2 March 2020 (UTC)<br />
<br />
:::I'm getting it in my browser... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 2 March 2020 (UTC)<br />
<br />
== SystemD user units depending on graphical session ==<br />
Hi,<br />
regarding reverting my addition to [[Systemd/User]], could you please explain why? I referenced [[https://www.freedesktop.org/software/systemd/man/systemd.special.html]] which directly contradicts what you said in your summary.<br />
<br />
{{unsigned|19:53, 5 May 2020|Fuero}}<br />
<br />
:The note in [[Systemd/User#How it works]] still applies - systemd services are never per-session, but per-user. The service does not magically get the correct DISPLAY or WAYLAND_DISPLAY variable, it does not work if you have multiple sessions per user, etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:45, 6 May 2020 (UTC)<br />
<br />
== Plymouth ==<br />
<br />
Actually with just Plymouth it does not work properly. Even 0dd17y had the same issue in https://bbs.archlinux.org/viewtopic.php?id=220900.<br />
<br />
The reason I did not file a bug report is that it is anyway fixed in the git version and the latest release (0.9.4) is around 2 years behind master<br />
<br />
{{unsigned|09:50, 6 May 2020|M.Srikanth}}<br />
<br />
:So if you don't have to file a bug report, add a full troubleshooting entry or at least properly reference your inline note instead of resorting to plain "if that does not work, try this instead". -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:15, 6 May 2020 (UTC)<br />
<br />
== [Bitcoin core] build the code and run the test suites ==<br />
<br />
Hello,<br />
<br />
This week, I managed to build the Bitcoin code and run all the test suites with the help of this page: https://jonatack.github.io/articles/how-to-compile-bitcoin-core-and-run-the-tests<br />
<br />
Archlinux has two particularities:<br />
* being in rolling release, it takes to manually use the library {{ic|Berkeley DB (BDB) v4.8}}<br />
* the {{ic|/tmp}} directory is by default limited to half the size of the Ram<br />
<br />
For these reason, maybe it could be interesting to have a page in the wiki to explain how to build the Bitcoin core?<br />
<br />
Cheers,<br />
<br />
Thomas<br />
<br />
[[User:Thomasb|Thomasb]] ([[User talk:Thomasb|talk]]) 20:29, 9 May 2020 (UTC)<br />
<br />
:I don't think that this is useful. There is the {{AUR|bitcoin-core-git}} package and nothing more should be needed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:53, 26 May 2020 (UTC)<br />
<br />
== Double linefeed results in extra line ==<br />
<br />
If you look at templates that end with double linefeed before noinclude this would result in extra line in resulting page.<br />
<br />
It may be a minor point but since you are perfectionist about wikitext I should mention this is a tradeoff and it results in slightly worse result.<br />
<br />
Removing just one linefeed removes the problem while still allowing it to not jumble all the tags into same line.<br />
<br />
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:30, 11 May 2020 (UTC)<br />
<br />
:If this is about [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=next&oldid=612179], the spaces I added back are not included when the template is used elsewhere, because the spaces are inside the noinclude tags. The extra space is only on the template page itself, but it does not result from template inclusion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:41, 11 May 2020 (UTC)<br />
<br />
::OFC, I mean the template page render has extra line. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 21:21, 11 May 2020 (UTC)<br />
<br />
:::I agree with [[User:Svito|Svito]], isn't it good to delete the extra blank lines? -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 05:39, 12 May 2020 (UTC)<br />
<br />
::::OK, let's do it. [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=616382&oldid=612181] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:47, 26 May 2020 (UTC)<br />
<br />
== Re: lighttpd: remove python2 version ==<br />
<br />
Instead of removing the example we could as well add an example using a Python3 library like https://pypi.org/project/flup6/.<br />
<br />
{{unsigned|15:23, 18 May 2020|Gruentee}}<br />
<br />
:Feel free to add it if you find it useful. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:56, 18 May 2020 (UTC)<br />
<br />
== Xbindkeys removal ==<br />
<br />
Hi, just wondering why you [https://wiki.archlinux.org/index.php?title=Xbindkeys&diff=617675&oldid=617670 removed my edit] from [[Xbindkeys]]? The xbindkeys page has a number of quick tips but no mention of how to bind anything to the Print Screen key so I thought it would be useful to add. -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 02:27, 3 June 2020 (UTC)<br />
<br />
:Giving examples for all keys on the keyboard is useless, there is [[Xbindkeys#Identifying keycodes]] which teaches how to find the keycodes and keysyms of any key. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 3 June 2020 (UTC)<br />
<br />
:: So how come you left the examples for the volume up/down and brightness? What is different between those examples and a screenshot example? Aren't more examples better to save people from hunting all over the place trying to piece things together themselves? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 14:03, 4 June 2020 (UTC)<br />
<br />
:::The difference is that when it comes to volume control, there are 1 or 2 options for the 99% most common cases, but for screenshot taking there are dozens of different options. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:15, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for edit to XDG Base Directory page regarding python_history ==<br />
<br />
I understand the justification for reverting the change I made, however I would like to point out that similar entries on the page (such as Maven) also have instructions for what contents to put in files (even though there is native documentation for those settings). Additionally, it took me a bit of re-reading on the linked Python documentation to reason out how the documentation's example needed to be modified, since it's not clear from the Python documentation whether placing such code in the PYTHONSTARTUP file will actually ''override'' the default behavior. [[User:Varriount|Varriount]] ([[User talk:Varriount|talk]]) 20:44, 20 June 2020 (UTC)<br />
<br />
:Even maven's note can be [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=631704&oldid=631630 shortened]. The notes in the table must be as short as possible, there is no place for extended explanations or long code snippets like in the upstream documentation. If the Python's documentation is not clear enough, I don't think any note in a massive convoluted table will ever be better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:47, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for Backlight page ==<br />
<br />
Hi, you reverted my change to [[Backlight]] page that mentioned WIP patches for controlling OLED panel brightness. I don't really understand justification for reverting it since currently the page says that OLED brightness can be controlled only by changing gamma ramp. That is wrong - since it's not the only way - these panels can control brightness with a PWM. Moreover controlling brightness with gamma ramp is not optimal - it essentially reduces dynamic range, i.e. at 50% you have 7 bits per pixel, at 25% - 6 bit per pixel, etc. That results in banding artifacts at lower brightness level.<br />
<br />
As far waiting for the patches to be merged before mentioning it there - it'll take ~3-6 months (yes, that's the process) and I haven't found *any* reference to these changes on the internet - everyone recommends using gamma ramp instead of fixing it properly. I'm absolutely sure that having information about these patches would not hurt [[User:Anarsoul|Anarsoul]] ([[User talk:Anarsoul|talk]]) 15:56, 30 June 2020 (UTC)<br />
<br />
:Linking to a repo which which has 2 custom commits on top of some arbitrary development version of the Linux kernel tree is not helpful for users. Nobody will compile directly from this repo which is already significantly outdated compared to recent kernel versions and there is no indication if the patches actually work with newer (or older) kernels. We can mention the PWM control as a general concept though. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:32, 12 August 2020 (UTC)<br />
<br />
== Automatic template correction ==<br />
<br />
Per [[Help:Template#Style]], templates should be used with the capitalization shown in the examples in their pages, so {{ic|&#123;{AUR&#124;...}} is correct, while {{ic|&#123;{aur&#124;...}} is not.<br />
<br />
However, there are pages that don't respect that rule (e.g. [[Android_Debug_Bridge]] until recently).<br />
<br />
I beleive this correction should be easy to implement using a bot. What do you think?<br />
<br />
{{unsigned|07:24, 25 August 2020|Relrel}}<br />
<br />
:Yes, this should be easy, but the bot should not make a huge amount of simple style-only changes - they should be combined with corrections for more complex rules. Anyway, there is an idea to create a [https://github.com/lahwaacz/wiki-scripts/issues/22 style linter] for the ArchWiki rules. Would you like to help? ;-) – [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:21, 25 August 2020 (UTC)<br />
<br />
== Failed to create tun device ==<br />
<br />
I don't understand your reason for [[https://wiki.archlinux.org/index.php?title=NetworkManager&diff=0&oldid=634880 removing my section in NetworkManager]]. Could you elaborate?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 07:40, 11 September 2020 (UTC)<br />
<br />
:You can't use [[systemd-networkd]] and [[NetworkManager]] at the same time. Even if you don't have any ''.network'' file for systemd-networkd, you can't solve NetworkManager's problems with systemd-networkd. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:43, 11 September 2020 (UTC)<br />
<br />
::Ok, thanks, in this case it solved the error I got. Now the VPN works. Do you have an idea about how to solve it without systemd-networkd?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 22:27, 11 September 2020 (UTC)<br />
<br />
:::You should really fix the permission problem for {{Pkg|networkmanager-openvpn}}. The tun interface should be managed by OpenVPN which needs rights to create it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 12 September 2020 (UTC)<br />
<br />
::I don't think this statement is entirely correct. [[systemd-networkd]] and [[NetworkManager]] can happily co-exist together if they are managing different interfaces. I unfortunately don't have a reference to point to this, but I came across this being mentioned a couple of times on forums. I personally use [[NetworkManager]] on my laptop to handle wifi, while [[systemd-networkd]] is in control of virtual ethernet and bridges for all my [[systemd-nspawn]] instances. [[User:Romstor|Romstor]] ([[User talk:Romstor|talk]]) 03:24, 12 September 2020 (UTC)<br />
<br />
== [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&oldid=636526/ XDG Base Directory]: Undo revision 636525 ==<br />
<br />
Dear Lahwaacz,<br />
<br />
maybe my changes were to rushed and from my point of view only. But I have two points to consider:<br />
<br />
# If I put the quotes around my vimrc and source it from my .bash_profile, I get the vim-error E471 (Argument required). Without quotes, this doesn't happen. So this change based on experience.<br />
# The rtp should includes directories, which are needed at runtime. (in plain vim e.g. ~/.vim). This is not a typical configuration directory. My mistake was, that I supposed that everyone put their vim plug-ins in $XDG_DATA_HOME and not in $XDG_CONFIG_HOME, because from my point of view a plug-in doesn't belong to the configuration. Maybe it is a good idea to add a remark, which explains the addition of $XDG_CONFIG_HOME to the rtp.<br />
<br />
[[User:Grrr|Grrr]] ([[User talk:Grrr|talk]]) 13:53, 26 September 2020 (UTC)<br />
<br />
# Quotes are there because $XDG_CONFIG_HOME may contain spaces.<br />
# It's not only about quotes - the runtimepath has subdirectories for color schemes, keymaps, autoload scripts etc.<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 26 September 2020 (UTC)<br />
<br />
== Readability in Wiki ==<br />
<br />
I noticed that you and the other admins and moderators often want sentences to continue endlessly, without line breaks.<br />
For example in the introduction of [[Wayland]].<br />
<br />
I think it would be better to have more seperated sentences, so it is easier to read and "important" information is easier visible for people.<br />
I don't know who is responsible, but maybe some options in MediaWiki (or whatever this wiki software is) could be changed as well, to make make line breaks etc. easier and reduce the height-space (if you know what I mean) between sentences, so it looks better, even though line breaks are used.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:38, 15 October 2020 (UTC) G3ro<br />
<br />
:I don't know exactly what you mean. Is it about the readability of the rendered HTML or the "source code" of the page? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:15, 15 October 2020 (UTC)<br />
<br />
:: Well I guess it can be about both. But mainly it is about what people see on the page.<br />
:: There are three seperate topics I mentioned:<br />
<br />
:: 1. Use line breaks: I would like to use more line breaks, because if you have long sentences that are written after each other without line breaks, it gets "harder" to recognize when the next sentence starts.<br />
:: While I agree to what you said somewhere, that sentences that belong directly together, should be written in one "paragraph", it would be useful for sentences that cover (slightly) different "topics" to be visibly parted.<br />
<br />
:: 2. Adjust margin options: I notice that when line breaks are used, there is a vertical space added between two sentences. Just like in this post. If you would use line breaks more often, this is a little too much spacing in my oppinion.<br />
<br />
:: 3. Potential options to make line breaks easier: It would be very convenient if a line break in the source code would lead to a line break in displayed text as well, instead of needing to add an empty line.<br />
<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:33, 15 October 2020 (UTC) G3ro<br />
<br />
:::OK, now I understand. I agree that splitting different topics usually improves legibility, but they should be split into separate paragraphs and not just by line breaks (e.g. using the &lt;br> tags). Paragraphs are semantic units whereas line breaks inside a paragraph are usually typographic errors.<br />
:::Also note that such splitting alone may not be enough to improve the text flow. For example, if we consider the intro for [[Wayland]], the second sentence about XWayland would not constitute a good paragraph - it is just a plain statement and the new topic is not nicely introduced. Ideally, you'd split the topic and make some wording changes for the second paragraph.<br />
:::As for the margin options, that is the difference between paragraph splitting and non-semantic line breaks. In my opinion, the styling is correct in this respect, as paragraphs should be discernible. You mentioned that you like line breaks to easily recognize where a sentence ends - but reading should be based on whole paragraphs, not sentences. There should be no reason to skip anything in the middle of a paragraph, otherwise it should be probably split into multiple paragraphs or otherwise rephrased.<br />
:::If you find it hard to follow a long sentence horizontally on a wide screen, we might consider enforcing some maximum width for the whole content. I think the readability would be better, since there would be more top-to-bottom eye movement at the cost of left-to-right-and-back.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:59, 15 October 2020 (UTC)<br />
<br />
== Xorg parentheses ==<br />
<br />
I actually think that X(org) is very useful to imply that it is one and the same thing.<br />
<br />
It might even be more confusing now, as we use both Xorg and X, because the wiki title and the package titles are Xorg.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:30, 17 October 2020 (UTC) G3ro<br />
<br />
:Well the conventions should be established on the [[Xorg]] page, not anywhere else... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:36, 17 October 2020 (UTC)<br />
<br />
:: Imo the conventions are established by upstream and they use a wide variety of X, X.org, X(org), Xorg etc.<br />
:: As I said I always prefer X(org) because then it is clear, that both are same thing.<br />
:: But ultimately it's your decision. <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:43, 17 October 2020 (UTC) G3ro<br />
<br />
:::When upstream is not capable of making a unambiguous decision, it makes sense that other projects pick some option and stick with it wherever they can to keep at least some consistency. So for this wiki, pages should use the same style as the [[Xorg]] page. But feel free to start a discussion about this in [[Talk:Xorg]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:56, 17 October 2020 (UTC)<br />
<br />
== SSHFS - systemd edit ==<br />
<br />
The edit was removed because "there is no advantage over using fstab entries".<br />
<br />
Is not only about the dis/advantages of the systemd option, is about that it is another possibility to achieve the task, that is why it was created in another level and the fstab section was left alone.<br />
<br />
Reconsider the edit as it presents another option which people can use.<br />
<br />
[[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 16:22, 22 October 2020 (UTC)<br />
<br />
:There is no need to use anything else, fstab just works well enough. Configuring mounts with systemd services is not a good idea - it is much more bloated than fstab and not the right tool for it. If anything, a different type of systemd units should be used: {{man|5|systemd.mount}}. But creating the mount units manually is still pretty useless since everything can be configured in fstab and systemd will generate the unit for you. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:22, 22 October 2020 (UTC)<br />
<br />
:: It is about the ability to use the user's .config file and all the proper options that are saved there. Also systemd gives the possibility to use different targets, so the user could mount it when an specific user logs in or when a graphical session starts. I could argue that bad a modification of fstab could lead to a system that doesnt boot, but such poorly configured systemd unit file just fails and the system is fine. Just give the user the information and let it decide what they can use depending on their use case. [[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 08:08, 24 October 2020 (UTC)<br />
<br />
:::You can configure systemd targets in fstab using the {{ic|x-systemd.wanted-by}} and {{ic|x-systemd.required-by}} options, there are also {{ic|nofail}} and {{ic|noauto}} options. Please read the {{man|5|systemd.mount}} manual.<br />
:::Using hosts from the user's {{ic|.ssh/config}} is the only thing which is not possible with fstab, but this does not warrant using the wrong tool for the task. Simple copy the full {{ic|user@hostname}} into fstab and you're done.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:47, 24 October 2020 (UTC)<br />
<br />
== [[Self-encrypting drives]] ==<br />
<br />
Hi, I'd like to respectfully disagree with the rollback. It's specific to sedutil that with most commands you need to input /dev/nvme0 (when encrypting the device) but for the sleep commands it requires /dev/nvme0n1 or it fails with a very unspecific error (Error saving the password to the kernel errno = 25), as found out in the discussion https://github.com/Drive-Trust-Alliance/sedutil/issues/90<br />
<br />
All in all I believe that it is important to keep this piece of information which was found out in a long discussion between the reporter and the developers. I ran into it and I believe many people may run into it, considering most of the new SSD will be NVMe. Best, [[User:Przemub|Przemub]] ([[User talk:Przemub|talk]]) 13:34, 28 October 2020 (UTC)<br />
<br />
:OK, then it makes sense. But it should be probably explained before, not in the section about the sleep command. Also please add the link to the note as a reference. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:27, 28 October 2020 (UTC)<br />
<br />
== Nvidia Installation ==<br />
<br />
The whole guide is unnecessary long and overcomplicated formulated.<br />
Shorter is better, most people will know their graphic card for example, so the determination etc. is only optional.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:21, 10 November 2020 (UTC) G3ro<br />
<br />
:Moving some info to some other page and leaving a tip behind does not make it shorter, but harder to follow. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:36, 10 November 2020 (UTC)<br />
<br />
== Btrfs layout ==<br />
<br />
Hi, Lahwaacz<br />
<br />
Thanks for maintaining [[Snapper]]! However I think the layout is not openSUSE specific and beneficial to all btrfs users. Can you elaborate your reason of undoing the edits? IMO the previous 'simple layout' complicates the rollback procedure.<br />
<br />
Cheers,<br />
[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 07:26, 3 December 2020 (UTC)<br />
<br />
:It is not overcomplicated, it is just doing things right. You can read about that in the forum thread, see the first note in [[Snapper#Suggested filesystem layout]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:24, 3 December 2020 (UTC)<br />
<br />
::Anyway I've moved the guides to my user page. It's not that I haven't read the 5-year-old forum post, it's that before the current layout I followed that post and resulted in a not fully rolled-back system. That post also sourced (then current) information from openSUSE. openSUSE has since massively overhauled the layout, as I pointed out in an edit you undid earlier.[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 09:02, 3 December 2020 (UTC)<br />
<br />
::Since last message I've extensively documented the new layout at [[User:I2Oc9/Btrfs_subvolumes]] and [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption]]. Have a look for yourself. Nothing new really, but IMO [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my take]] is much more simpler and complete than the supposedly [[Snapper#Restoring_/_to_a_previous_snapshot_of_@|simpler one]]. That one does not leverage native {{ic|snapper rollback}} or {{Pkg|grub-btrfs}}, among other things. I strongly suggest you try if you have time. [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 11:55, 3 December 2020 (UTC)<br />
<br />
::Actually if you look closely, none of [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my recovery methods]] is specific to [[User:I2Oc9/Btrfs_subvolumes#A_new_kind_of_layout|the new 'complex' layout]], it will work totally fine with the old one. I just don't think moving @ around in live environment is appropriate.<br />
<br />
::On the other hand, the layout recommendation has been updated by openSUSE [https://en.opensuse.org/SDB:BTRFS], why stick with the old one? [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 12:37, 3 December 2020 (UTC)<br />
<br />
:::The main reasons why I reverted your edits on the [[Snapper]] page are: 1) it was a huge change which was not discussed previously as required by [[ArchWiki:Contributing#The 3 fundamental rules]], and 2) it has some elements which do not apply to Arch (see below). If you wish to propose a better layout of the subvolumes, it should be discussed in [[Talk:Snapper]] first. Your user pages would serve as great drafts.<br />
:::Note that the current suggested layout is not ''flat'' in the sense of [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|your section]] - it has a separate subvolume for {{ic|.snapshots}} so it does not lead to the recursive mess. So your proposed layout seemed very similar to the current suggested layout. The real difference is which subvolume gets mounted at {{ic|/}}, but I did not find it explained anywhere on the Snapper page before I reverted the changes (I get it now from your user page). I also did not find a proper documentation of the openSUSE's layout - it seems to be just the product of their installer and the documentation only deals with the result, saying at most that [https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-snapper.html#sec-snapper-snapshot-boot the subvolume configuration must not be changed] for rollbacks to work.<br />
:::Now the openSUSE-specific elements: some Arch packages actually install software into {{ic|/opt}}, so the recommended layout should not suggest a separate subvolume for this path. Even more importantly, the pacman database is located at {{ic|/var/lib/pacman/local/}} and it must be rolled back along with the system, so there should be no separate subvolume for {{ic|/var}}. Instead, users should be encouraged to create (even nested) subvolumes for specific data directories under {{ic|/var}}, such as {{ic|/var/log}}, {{ic|/var/tmp}}, {{ic|/var/cache/pacman}}, {{ic|/var/lib/machines}}, etc.<br />
:::Finally, the suggested layout should not be GRUB-specific, there should be no recommendations regarding a boot loader. Sure it is useful to include non-trivial tips, but people may actually use a different boot loader.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:31, 4 December 2020 (UTC)<br />
<br />
::::Thanks for your detailed reply. I admit that I'm not knowledgeable on the intricate differences between distributions and shouldn't have made the changes without properly discussing them first.<br />
::::Yes, I get that the current layout is not [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|the one described in this section]] and indeed properly separates {{ic|/.snapshot}} and {{ic|/}}. The layout I proposed attempts to add some "niceties" such as supporting multi-distribution installations (complex and unnecessary, I agree) and bring the openSUSE layout here, which is a mistake, as you've pointed out.<br />
::::As for GRUB, since I use LUKS all the time and it's the only bootloader supporting encrypted {{ic|/boot}} on Btrfs on LUKS1, I really didn't think of any other possibilities.<br />
::::I will incorporate your recommendations to my user page and add a new section in [[Talk:Snapper]] pointing to those pages.<br />
::::Cheers -- [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:09, 4 December 2020 (UTC)<br />
<br />
:::::I've adopted [[Install_Arch_Linux_on_ZFS#System_datasets|Archlinux Root on ZFS layout]] to [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Create_subvolumes|my proposal]]. [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:56, 4 December 2020 (UTC)<br />
<br />
== Reflector Revert ==<br />
<br />
Hi Lahwaacz, about your [https://wiki.archlinux.org/index.php?title=Reflector&oldid=643749 revert], it seems like there's precedence for including AUR packages that replicate the code on the wiki. For example, in [[dash#Relinking /bin/sh]].<br />
<br />
In addition, I believe that there's value for linking the AUR package because it allows a simpler user experience where the AUR package is maintained for them. That way, if it is ever updated, they can easily fetch the update instead of religiously checking the wiki page (which most users probably don't do).<br />
<br />
Thanks!<br />
<br />
[[User:Denton-l|Denton-l]] ([[User talk:Denton-l|talk]]) 01:52, 7 December 2020 (UTC)<br />
<br />
:That precedence was only created by [https://wiki.archlinux.org/index.php?title=Dash&type=revision&diff=561587&oldid=518398 yourself]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 5 May 2021 (UTC)<br />
<br />
== firefox zoom ==<br />
<br />
"no reason to zoom manually, see HiDPI)" - fractional scaling doesn't work [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 26 December 2020 (UTC)<br />
<br />
:That should be explained in [[HiDPI#Firefox]] anyway. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:48, 26 December 2020 (UTC)<br />
<br />
::it's good to have this mentioned somewhere clearly so people know about it before they say "fonts on linux suck" [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 15:51, 29 December 2020 (UTC)<br />
<br />
== Intel GVT-g edits ==<br />
<br />
Hello Lahwaacz,<br />
<br />
I have noticed that you reverted one of the edits I have performed on [[Intel_GVT-g]].<br />
<br />
About this revert: [https://wiki.archlinux.org/index.php?title=Intel_GVT-g&oldid=648062 Windows problems are out of scope]<br />
<br />
While I understand that the ArchWiki is about ArchLinux, this article in particular mentions Windows in the introduction, and already includes another troubleshooting point about Windows. The issue I have encountered with the black bars is somewhat common, as I have found other people discussing it online, and I really fail to see why not including this piece of information in this article would be better than including it.<br />
<br />
Please, let me know your thoughts. If you think that the point can be improved, I will be happy to do that.<br />
<br />
Ciao,<br />
<br />
[[User:Wilcomir|Wilcomir]] ([[User talk:Wilcomir|talk]]) 09:14, 3 January 2021 (UTC)<br />
<br />
:Well, the existing section about a Windows problem is actually solved by configuring the Linux host. I think anything involving configuration or installation of programs in Windows is not appropriate for long troubleshooting sections. At most, they could be mentioned in a short reference to other sites which describe the problem in detail. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:34, 3 January 2021 (UTC)<br />
<br />
== <s>XDG configuration for Vim</s> ==<br />
<br />
Hi Lahwaacz,<br />
<br />
You have reverted the updated Notes for Vim on [[XDG Base Directory]], because "copy-pasted from a blog post".<br />
<br />
The problem is, not only is the configuration presented currently also copied from a blog post too, but is already 10 years old.<br />
<br />
Would it be OK, if we bring back the more up to date version? Or at least remove the obsolete one and leave link to newer?<br><br />
(Although I think a copy on wiki would be beneficial in case my blog ceases to exist)<br />
<br />
[[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 02:05, 12 January 2021 (UTC)<br />
<br />
:OK let's close this. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:49, 29 August 2021 (UTC)<br />
<br />
== Root on ZFS draft ==<br />
<br />
Hi, I submitted [https://github.com/openzfs/openzfs-docs/pull/104 a Root on ZFS draft] to official doc repo.<br />
<br />
In the draft, the following directories are separated from root filesystem:<br />
home,root,srv,usr/local,var/log,var/spool,var/tmp<br />
<br />
Is this appropriate for Arch Linux? Or do you have any suggestion on the draft?<br />
Any comment is appreciated.<br />
[[User:M0p|M0p]] ([[User talk:M0p|talk]]) 01:28, 23 January 2021 (UTC)<br />
<br />
== Re: undo GRUB - Common installation errors ==<br />
<br />
Concerning your undo of [https://wiki.archlinux.org/index.php?title=GRUB&diff=next&oldid=649799 Add the error message `Could not prepare Boot variable: No space left on device`)]<br />
Is there a better place to for this Information? One can find the solution in various forums, but I thought it could be helpful to have it in this wiki somewhere. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 12:51, 25 January 2021 (UTC)<br />
<br />
:The error message is not specific to the {{ic|/sys/fs/pstore/}} filesystem (which does not even seem to be used by default on Arch...) Where did you find that? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:16, 25 January 2021 (UTC)<br />
<br />
::I did not find anything Arch specific, but this post about Debian helped: [https://donjajo.com/fix-grub-efibootmgr-not-set-variable-no-space-left-device/ Post]. I also found something about [https://askubuntu.com/questions/1072618/could-not-prepare-boot-variable-no-space-left-on-device-grub-install-error-ef /sys/fs/efi/efivars/dump-*] The problem is that the actual efi-partition does not seam to be the problem, there is more than 70% space left. If there is better information to guide the user in the right direction that wuld be more helpful. This is what I found worked, but I admit that I don't know much about how grub operates. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 16:20, 25 January 2021 (UTC)<br />
<br />
:::This wiki ''is'' Arch specific so old posts about Debian or Ubuntu do not apply. Even if they did, this is hardly a ''common'' installation problem. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:29, 26 January 2021 (UTC)<br />
<br />
::::I know that, and would not have put it there if it didn't occur on my Arch Linux installation. If this is something that should not be documented in this wiki, I understand that. Is there any other place you would recommend? An issue for grub-install maybe? [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 22:24, 26 January 2021 (UTC)<br />
<br />
== Kernel Compilation time ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Kernel&diff=next&oldid=650896 link]<br />
<br />
I don't think we should judge information by what is obvious to experts.<br />
People might have experience with compilation of other programs, which mostly is fast, and then there is the kernel which takes forever to compile.<br />
I think it does not hurt anyone to make people aware of it.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:03, 6 February 2021 (UTC)<br />
<br />
:It is an unnecessary information without a definite answer which can even be [https://html.duckduckgo.com/html?q=how%20long%20does%20it%20take%20to%20compile%20Linux%20kernel searched elsewhere]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:23, 6 February 2021 (UTC)<br />
<br />
:: I disagree, with that argument nearly any tip and note is unnecessary. These things are intended to inform users about things that should be taken into consideration and that are different from the norm.<br />
:: Also do you search for the compilation time for every program you intend to compile? I don't.<br />
:: Furthermore this info is included, why not tell it to people directly on the start, so they don't read over it? <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:36, 6 February 2021 (UTC)<br />
<br />
:::If someone wants to compile the Linux kernel, they should obviously expect that it will take ''some time''. Stating that it "can take up to several hours" does not make sense without referring to a specific hardware. Obviously, it will take much longer on a poor laptop than on a powerful workstation with a many-core processor, but people can assume that themselves. Without a reference to a specific hardware, the note is unnecessarily discouraging because the compilation can be as fast as some tens of minutes - it is by far not the most expensive package to compile...<br />
:::As you said, people can find better notes later along with advices to enable parallel build etc. which is all that's needed IMO.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:03, 6 February 2021 (UTC)<br />
<br />
== Wayland style ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Wayland&diff=prev&oldid=650979 link]<br />
<br />
I think in the old version it was much easier to read the "source code", so I don't see why there can't be spaces between it.<br />
Things shouldn't be complicated more than necessary.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:11, 6 February 2021 (UTC)<br />
<br />
:Most templates on the wiki are written without spaces around the |. When we [https://github.com/archlinux/archwiki/pull/32 switch the editor], there will even be syntax highlighting. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:25, 6 February 2021 (UTC)<br />
<br />
== Bluetooth keyboard ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php/Bluetooth_keyboard link]<br />
<br />
On your last change you said "not specific to keyboards, all of this is already mentioned on the Bluetooth page", the point is that this is extremely relevant for bluetooth keyboard since it is required to perform the login! If this little piece cannot be duplicated I would suggest at least to leave a link saying "If you want to autoconnect at boot please refer to...". I'm new here and I would not touch it further, but please evaluate the suggestion (this is because after reading bluetooth keyboard page and not finding the solution I had to look for it on forums)<br />
<br />
{{unsigned|21:17, 20 February 2021|Stevexyz}}<br />
<br />
:Well, basically the whole page is flagged to be merged with the main [[Bluetooth]] page, so it's expected to be incomplete. Other tips may always be found on a more general page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:40, 21 February 2021 (UTC)<br />
<br />
== Re: Steam Needs to be online error ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Steam/Troubleshooting&diff=next&oldid=653073 link]<br />
<br />
The problem here is that DNS resolution in general works already (yes even outside browsers), i.e. <br />
<br />
dig media.steampowered.com<br />
<br />
would run successfully, but the Steam client couldn’t resolve it. The DNS request from 'dig' shows up in my nameserver’s log, the one Steam should send doesn’t. This indicates it might indeed a problem specific to Steam, and it’s not as easy as just say "go fix your DNS resolution", as it already may work correctly for everything but Steam.<br />
<br />
Additionally, at no point does [[Domain name resolution]] even mention nscd, so you effectively removed a fix/workaround for the problem from the Wiki. So I was definitely not "duplicating an article" here. [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 08:12, 22 February 2021 (UTC)<br />
<br />
:Could I please hear your opinion on this? I’d be happy to just add something along the lines of "if you made sure DNS resolution works but Steam still can’t resolve it, try additionally enabling the nscd service" to the Steam troubleshooting page. Unfortounately I don’t know why running the service helps, but I’d still like to give others an easier time finding this solution than I had myself. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 09:15, 28 February 2021 (UTC)<br />
<br />
::Hi, I'm sorry for the delay. Could you test if using a different program for DNS caching (e.g. [[systemd-resolved]]) instead of {{ic|nscd.service}} fixes the problem? If not, then it's probably not due to DNS - {{man|8|nscd}} actually caches more than just DNS. Also if you have a reference to some website where you found about nscd, it would be nice to add it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 28 February 2021 (UTC)<br />
<br />
:::No worries. Using [[systemd-resolved]] for DNS resolution (and caching I guess, I wasn’t aware it does that, too) was a thing I did try, but that didn’t fix it for me. The place I found out about nscd fixing it was actually the [https://bbs.archlinux.org/viewtopic.php?id=263356 Arch forums]. When I search the web for Steam in combination with nscd, all I can seem to find are more forum entries of people that don’t know why that fixes it either. I can try a bit to find out what nscd does to make it work, but I’m not too confident I will be successful. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 14:51, 28 February 2021 (UTC)<br />
<br />
::::Okay, so {{ic|nscd}} allows to [https://man7.org/linux/man-pages/man5/nscd.conf.5.html dis-/enable caching per service], and it’s indeed enabling it for {{ic|hosts}} that makes it work. That’s weird though, since [[systemd-resolved]] has caching enabled by default, and using it for resolution didn’t make {{ic|steam}} work for me. Leads me to think that I didn’t set it up correctly, although resolving via {{ic|dig}} *did* work. Since [[steam]] depends on [[Name Service Switch]], I tried resolving using {{ic|getent}} manually with nscd disabled, but that worked while steam did not. I’m not really sure what to make of this, since I have no idea how this low level networking/resolving stuff works really. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 15:39, 28 February 2021 (UTC)<br />
<br />
:::::Hmm, I don't know the details either. Steam needs the multilib packages so maybe that's part of the problem. Could you add your findings to the section and use [[Template:Expansion]] for the missing details? Maybe someone can figure it out. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:44, 28 February 2021 (UTC)<br />
<br />
::::::Sure, I can do that. I’ll probably need a minute to figure out how to use the template though, but I should have the time later today. Thanks for your input on this. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 17:56, 28 February 2021 (UTC)<br />
<br />
== Removal of website link ==<br />
<br />
Refers to this: https://wiki.archlinux.org/index.php?title=PipeWire&diff=next&oldid=653701<br />
<br />
I don't understand why that has to be removed. The official website should be always worth a mention, even if it is somehow mentioned in the text already.<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:02, 28 February 2021 (UTC)<br />
<br />
:The "See also" section is for additional links, it is not intended as a collection of all links used on a page. Adding links which are clearly mentioned in the appropriate place only clutters the list. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:24, 28 February 2021 (UTC)<br />
<br />
:: There are just three links and only one of them is really useful, the others could maybe even be removed as they link to old blog posts.<br />
:: I can only repeat myself, that things don't always have to be made more complicated than necessary.<br />
:: The official website is a central point which links to many more useful ressources, so it's one link for much information.<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:34, 28 February 2021 (UTC)<br />
<br />
== Removal of bootia32.efi generation procedure from X205TA install page. ==<br />
<br />
Those [https://wiki.archlinux.org/index.php?title=ASUS_x205ta&diff=596239&oldid=562734 instructions] were really straightforward and useful, imho in comparison present ones require too much material to be confident with. I think it's (paradoxically) way easier to generate the file than to configure a `grub.cfg` from zero to boot a live cd. Can we undo the edit? Otherwise we could put them in a new page or section in the GRUB page and link to them maybe. [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 05:07, 4 March 2021 (UTC)<br />
<br />
:If there is something wrong with the information on the [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Booting_64-bit_kernel_on_32-bit_UEFI general page], it should be improved instead of describing the same procedure in a different way on a completely unrelated page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:16, 6 March 2021 (UTC)<br />
<br />
:: I didn't know we had that info in the UEFI article. I think it could be appropriate to insert the [https://en.wikipedia.org/wiki/Template:See_also#Examples See also] archwiki equivalent (which I couldn't find) for UEFI page on top of the aforementioned section, what do you think? [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 13:28, 7 March 2021 (UTC)<br />
<br />
:::Well, the removed section was previously flagged with "Duplicates [[Unified Extensible Firmware Interface#Booting 64-bit kernel on 32-bit UEFI]]"...<br />
:::Also the laptops pages are usually related to most of the general pages on this wiki, adding all of them would be pretty useless. Users should not expect to find everything on a single laptop page, they should always check if there is a general page for their topic with more details.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:58, 7 March 2021 (UTC)<br />
<br />
== Re: Show how to use systemd/Timers with wg-quick@.service ==<br />
<br />
I don't think using service is the appropriate when you want to start Wireguard at boot. For most people connecting to a VPN is not exactly part system startup.<br />
A timer should more appropriate.<br />
[[User:ENV25|ENV25]] ([[User talk:ENV25|talk]]) 10:03, 11 April 2021 (UTC)<br />
<br />
:I don't see how OnBootSec=1min is more appropriate than an automatically starting service. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:19, 11 April 2021 (UTC)<br />
<br />
== USB flash installation medium (BIOS bootable) ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=next&oldid=673926 revert]: "making the partition bootable is discussed below"<br />
Do you mean installing syslinux and `dd` the [gpt]mbr with "discussed below"? This was not enought for my setup (Sandisk Ultra 64GB, Dell XPS 9370) to make the partition BIOS bootable. It did work right after I checked "Legacy BIOS Bootable" checkbox using gnome-disks.<br />
<br />
{{Unsigned|13:42, 30 May 2021 (UTC)|Auipga}}<br />
<br />
:Yes, that's what I meant. If it does not work, it should be fixed rather than providing a duplicate instruction without a reason. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:16, 30 May 2021 (UTC)<br />
<br />
== Systemd-networkd systemd-networkd-wait-online.service discussion modifications ==<br />
<br />
I'm not sure why you're reverting my edits.<br />
<br />
You said: "''empty ExecStart is explained in Systemd#Examples''"<br />
<br />
Exactly: Systemd#Examples clearly states "''As another example, in order to replace the ExecStart directive for a unit that is '''not of type oneshot'''''"<br />
<br />
'''systemd-networkd-wait-online''' is a oneshot service. By having the superfluous empty ExecStart you're just confusing people.<br />
<br />
Regarding the file naming, yes the name is irrelevant, but it's generally helpful to non-expert users to stick to canonical naming conventions.<br />
<br />
Please make sure you're on solid ground before reverting edits; you're just discouraging people from engaging with the Wiki. Thanks. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 16:51, 9 June 2021 (UTC)<br />
<br />
:{{man|5|systemd.service}} says: "Unless Type= is oneshot, exactly one command must be given. When Type=oneshot is used, zero or more commands may be specified."<br />
:So when a service is not oneshot, users ''must'' clear ExecStart before adding a modified command in the drop-in file. If a service is oneshot, they ''may or may not'' clear ExecStart, since the service may have multiple ExecStart commands.<br />
:In case of systemd-networkd-wait-online, I don't see why you would want to run multiple instances with different options: one to wait for ''all'' links (which is the default command) and another one to wait for ''any'' link (which is the command in the drop-in example). So clearing ExecStart really makes sense for systemd-networkd-wait-online.<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:44, 9 June 2021 (UTC)<br />
<br />
== Pacman: Install missing dependencies ==<br />
<br />
Hi. [https://wiki.archlinux.org/index.php?title=Pacman&type=revision&diff=690774&oldid=690762 "Pacman" Revision as of 21:50, 4 August 2021 (undo)] - maybe at least put that into [[System_maintenance#Avoid_certain_pacman_commands]]?<br />
<br />
[[User:Galeksandrp|Galeksandrp]] ([[User talk:Galeksandrp|talk]])<br />
<br />
:[[System_maintenance#Avoid_certain_pacman_commands]] already mentions {{ic|-Rdd}}. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:12, 14 August 2021 (UTC)<br />
<br />
== DPMS: "\033[9;0]" ==<br />
<br />
Hi. It seems that you removed {{ic|echo -ne "\033[9;0]"}} from [[Display Power Management Signaling|DPMS]]<br />
<br />
https://wiki.archlinux.org/index.php?title=Display_Power_Management_Signaling&diff=629705&oldid=625073<br />
<br />
[https://www.denx.de/wiki/view/DULG/SwitchOffScreenSaverAndBlinkingCursor A DULG page] and [https://unix.stackexchange.com/a/23636 a U&L post] brought me here.<br />
<br />
May I ask (1) if this method is still working; and (2) where is this escape sequence documented? [not found in {{man|4|console_codes}}]<br />
<br />
Thanks.<br />
<br />
{{Unsigned|05:23, 15 August 2021 (UTC)|PXf}}<br />
<br />
:[[Display Power Management Signaling#DPMS interaction in a Linux console with setterm]] says that setterm works by writing escape codes to the terminal device. The first subsection shows how to reverse-engineer the escape codes. Note that the escape codes are an implementation detail that users should not be concerned with, their documentation is certainly not our job. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:40, 15 August 2021 (UTC)<br />
<br />
== Linux console/Keyboard configuration ==<br />
<br />
Hi, you recently reverted my edit https://wiki.archlinux.org/index.php?title=Linux_console/Keyboard_configuration&oldid=693887. The reason I made that edit, was that I used to put my custom keymap in {{ic|/usr/local/share/kbd/keymaps/personal}} per the previous version of the wiki page. But this doesn't work with ''sd-vconsole'', as it's include files don't get loaded. Your suggested workaround by adding all required files using [[mkinitcpio#BINARIES and FILES|mkinitcpio BINARIES and FILES]] is rather tedious, as all the include files need to be in there, added by hand. This is done automatically by ''sd-vconsole'' if the file was put in {{ic|/usr/share/kbd/keymaps/}}. The reason I made this edit is due to https://bugs.archlinux.org/task/71788. See Giancarlo Razzolini's comment. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:43, 2 September 2021 (UTC)<br />
<br />
:It's just one custom file under {{ic|/usr/local}} and one entry in {{ic|FILES}}. What is so tedious about it? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:37, 2 September 2021 (UTC)<br />
<br />
:: It's not just one file. All the dependencies need to be included too under {{ic|/usr/share/kbd/keymaps/}}. There are quite a few in my case, when I just include ''us.map'' to modify it slightly. See the ''sd-vconsole'' hook script. That script has a part where it finds all the dependencies of a keymap.<br />
<br />
:: * ''/usr/share/kbd/keymaps/i386/include/compose.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/euro1.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-keys-bare.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-with-alt-and-altgr.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/qwerty-layout.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/personal.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/us.map''<br />
:: * ''/usr/share/kbd/keymaps/include/compose.latin1''<br />
<br />
:: [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 12:01, 2 September 2021 (UTC)<br />
<br />
::: I moved this to the talk page so I remember it and others can discuss too. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:18, 4 September 2021 (UTC)<br />
<br />
::: Oh, I see. In that case I suggest we add a tip like this:<br />
::: {{Tip|If you use the {{ic|sd-vconsole}} [[mkinitcpio#Common hooks|mkinitcpio hook]] instead of {{ic|keymap}}, keymaps located under {{ic|/usr/local}} as well as their dependencies from {{ic|/usr/share/kbd/keymaps}} need to be manually specified in the {{ic|FILES}} array in {{ic|mkinitcpio.conf}}. On the other hand, custom files located in {{ic|/usr/share/kbd/keymaps}} will be added automatically when configured in {{ic|/etc/vconsole.conf}}.}}<br />
::: Because this is relevant only for people using the {{ic|sd-vconsole}} hook and otherwise it does not make sense to pollute {{ic|/usr/share/kbd/keymaps}} with custom files.<br />
::: — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:55, 5 September 2021 (UTC)<br />
<br />
== cow_* ==<br />
<br />
Hi Lahwaacz. About the [https://wiki.archlinux.org/index.php?title=Archiso&diff=next&oldid=692981 how/why issue] (there will be no more &lt;!-- --&gt;). What if, for once, that I want to install some large packages after booting archiso, and would not bother modifying packages.x86_64 and building again? [https://www.memesmonkey.com/topic/works+on+my+machine <s>''on my machine''</s>] Darren "Un1Gfn" "[[User:PXf|PXf]]" Ng ([[User talk:PXf|talk]]) 08:18, 12 October 2021 (UTC)<br />
<br />
:It is a subsection of "Tips and tricks", not "Troubleshooting", so it should start with a clear motivation saying ''why'' the tip is useful, rather than an error message that the user has no idea if they will face or not. If you have such description, feel free to rewrite the section. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 05:42, 13 October 2021 (UTC)<br />
<br />
::What about making it a subsection of "[[Archiso#Troubleshooting|Troubleshooting]]" and renaming it to {{ic|partition / too full}}? [[User:PXf|PXf]] ([[User talk:PXf|talk]]) 06:45, 13 October 2021 (UTC)<br />
<br />
:::It's better to motivate it as a tip/trick rather than solve the problem after it happens. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:48, 13 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
(Undo revision 699881 by Oliver (talk) - installing arch-install-scripts does not get the image to "the same footing" as the archiso, even installing something for the first time is not an excuse to violate Help:Style#Package management instructions)<br />
<br />
'the same footing' may be poor choice of wording maybe but it's also not false. You are in a SIMILAR place, not 'exactly identical to the dot' e.g. same footing<br />
<br />
but 'installing something for the first time' is NOT what is going on here really. If we quote the style guide:<br />
<br />
''every Arch user should know pacman's article by memory''<br />
<br />
<br />
The thing is, this is NOT an Arch user yet. They have no idea what's going on, how to do stuff and just want to get started and installed. You can't expect _new_ not-yet-a user, to figure out everything in a daunting installation; by being a smart-bum about it. Yes, the style guide is completely correct on all other points. But I would think that this is the exception, rather then the rule. Help your new users a little. Introduce them gentle with open arms. From a 'first UX kind of way, this is horrible to treat your potentially new users.<br />
<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 17:40, 26 October 2021 (UTC)<br />
<br />
:We use the same convention on the [[Installation guide]] itself. They should read the [[pacman]] page to learn how to install packages as soon as possible, so why not right when they use it for the first time? There is a gentle link to "[[install]]" before the package name, so the clueless user will follow the link and learn something. They will not learn anything by copy-pasting a quick one-liner. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 26 October 2021 (UTC)<br />
<br />
Yes, you ARE right, however; this is the install guide (relatively speaking) Let them install the system first with a gentle nudge; THEN force them to learn stuff :p<br />
<br />
Again, I understand the policy and the reasoning behind it very much so; but it's those first few steps that are the hardest. It's birds vs humans I suppose; birds throw their children out of their nests to teach them to fly (or die); Humans raise their children first in a more gentle manor. Is arch really the 'l337 fly or die, rtfm n00b' kind of distro?<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 18:25, 26 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
skip the rsync protocol<br />
<br />
As per my 'commit message' The user is confronted with the following:<br />
WARNING: failed to rate rsync download (rsync://mirror.erickochen.nl/archlinux/community/os/x86_64/community.db): [Errno 2] No such file or directory: 'rsync'<br />
<br />
You really think we should not reflect this in the documentation for now, until this dependency is actually properly resolved in the package? (could be weeks?)</div>Oliverhttps://wiki.archlinux.org/index.php?title=User_talk:Lahwaacz&diff=700019User talk:Lahwaacz2021-10-26T18:30:59Z<p>Oliver: /* Install Arch Linux via Docker */ new section</p>
<hr />
<div>== bot checking links after move ==<br />
<br />
Hi, re [[Talk:Touchpad Synaptics#adding libinput alternative]]. [[Touchpad Synaptics]] has 100+ backlinks and the more important ones - a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of [[Touchpad Synaptics]] and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:36, 26 September 2015 (UTC)<br />
<br />
:Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a [[UUID]] page, which was later generalized and renamed to [[Persistent block device naming]] and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace <nowiki>[[pacman|Install]]</nowiki> with <nowiki>[[Install]]</nowiki> etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:01, 26 September 2015 (UTC)<br />
<br />
::Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [https://wiki.archlinux.org/index.php/Special:WhatLinksHere/Beginners'_Guide]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:02, 26 September 2015 (UTC)<br />
<br />
== mkosi ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=Systemd-nspawn&diff=0&oldid=491975 revert]: You can use mkosi also to create a container/directory tree (-t directory). So it can do the same and more. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 11:33, 1 October 2017 (UTC)<br />
<br />
:Alright, how is the "more" relevant to systemd-nspawn though? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:30, 3 October 2017 (UTC)<br />
<br />
::Hi, mkosi let's you create images (or directory trees) of various different distributions and allows you to do things like setting the root-password or installing additional packages. systemd-nspawn alows you to boot such images/directory trees. So I thought mentioning mkosi as alternative to manually creating a container with pacstrap or debootstrap would be worth it. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 22:23, 5 October 2017 (UTC)<br />
<br />
== Waking from suspend with USB device ==<br />
<br />
Hi Lahwaacz, thanks for your input on this topic.<br />
Can you help me a bit further, I know the USB host controller and the USB device are different things but I thought that enabling the host controller was not necessary anymore, see [https://www.spinics.net/lists/linux-usb/msg53661.html].<br />
In my case all the {{ic|driver/*/power/wakeup}} are all enabled by default and the {{ic|/proc/acpi/wakeup}} as well.<br />
Anyway I have added a step in my explanations to identify the path awaiting for more clarity.<br />
<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 21:57, 16 January 2018 (UTC)<br />
<br />
:Hi, thanks for the link, it's entirely possible that something changed since the section was written. However, in my case only the keyboard device has wakeup enabled by default: {{bc|<nowiki><br />
$ for f in /sys/bus/usb/drivers/usb/*/power/wakeup; do echo "$f: $(cat $f)"; done<br />
/sys/bus/usb/drivers/usb/1-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/2-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-11/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-12/power/wakeup: enabled<br />
/sys/bus/usb/drivers/usb/3-13/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-4/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb2/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb4/power/wakeup: disabled<br />
</nowiki>}}<br />
:But in practice it seems to wake up the system even without the host controllers enabled for wakeup... It might also depend on some BIOS/firmware settings but if it works by default on most systems then I think the host controller settings could be removed again.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:14, 19 January 2018 (UTC)<br />
<br />
== Are supported local/remote destinations important for choosing a backup program? ==<br />
<br />
You [[Special:Diff/525550|reverted]] my edit adding supported backup destinations to [[Synchronization_and_backup_programs]]. This is puzzling to me. Here are some thoughts:<br />
* if choosing any backup program, the ability to send the backup off-site vs only on a local disk is a key feature consideration. Perhaps *the* key feature: one helps me recover in case my house gets burglarized or burns down, and the other does not. This is a much more important feature consideration than, say, whether the program is written in Go or Mono (something that has a full column). I think it's hard to disagree on that.<br />
* Given this, I am very puzzled you would use the term "useless" in the revert message.<br />
* I assume you didn't like that the table got even bigger (it didn't fit into the layout even before). I don't like it either, but perhaps the revert should have said "can you put this somewhere else, not in this already-too-big table?"<br />
* On a personal note, when I provide feedback or give opinion on somebody else's work, I'd like to be constructive and kind, instead of aggressive and putting people down. Just a thought. Thanks for listening.<br />
<br />
[[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 17:38, 11 June 2018 (UTC)<br />
<br />
:No because you can use any remote back-end with any backup application by just running one command / writing the backups to a [[FUSE]] (if available).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:39, 12 June 2018 (UTC)<br />
<br />
::Hmm, by that reasoning we don't need the Arch package repository, as long as we have source code and makepkg. Or Perl, if we have bash and awk. But even then, and if all the fuse backends existed (I doubt they do), and if it were easy to set all of them up (another thing I doubt), do you indeed believe that running something written to read/write local files will be just as efficient backing up gigabytes of data to a remote repository as something that is specifically optimized for that use case? Note that backing up, say, daily, a typical hard drive via tpyical consumer broadband is still quite a bandwidth challenge in many places today. What about we add this info, and remove (or merge) some other columns to make the table smaller? {{Unsigned|18:08, 12 June 2018|Jernst}}<br />
<br />
:::Your comparisons don't make sense. Mind the slash in my response, you do not need a FUSE implementation, a simple CLI suffices. You do not need to "set all of them up", you only need one. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 18:47, 12 June 2018 (UTC)<br />
<br />
::::If you ever attempt to help a normal user set up a reliably-working off-site backup strategy, think of this discussion. In the meantime, this is all the time I'm going to spend on a discussion that has such repeated gems in it as "makes no sense" without explaining why you think so. Have a nice day. [[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 18:54, 12 June 2018 (UTC)<br />
<br />
== The pip section in [[Python package guidelines]] ==<br />
<br />
Hi, you wanted the warning about using pip or wheels restored but accidentally(?) reverted my whole set of changes. I redid them, leaving the warning in place. – [[User:Flying sheep|flying sheep]] 08:17, 8 March 2019 (UTC)<br />
<br />
:Full revert was intentional, because the "wheel" section is not a full replacement for "pip" because there are packages which don't provide wheel files. As I said in the edit summary, there is no reason to recommend one or the other due to the warning. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 8 March 2019 (UTC)<br />
::That still doesn’t explain why you reverted the first part, that had nothing to do with the pip/wheel section and simple improves the files.pythonhosted.org URLs. I restored that one while we’re discussing the pip/wheel section. And about that: There’s no reason to use pip for anything else, and pip is only used because some people (me included) didn’t understand that you can install most wheels by just extracting them to the correct location. So what do you think is missing from my wheels section that the former pip section had? – [[User:Flying_sheep|flying sheep]] 11:41, 11 March 2019 (UTC)<br />
<br />
:::If you didn't notice, the page includes "guidelines" in the title. So the page should contain only common and recommended ways to do things, not everything that is possible to do. If you think that your way to install "wheels" should be followed by everybody, feel free to discuss it on the talk page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:26, 11 March 2019 (UTC)<br />
::::Well, extracting static archives sounds much more recommended than running pip with like 7 options to make it behave. I added a talk item: [[Talk:Python package guidelines#Remove_pip_section_in_favor_of_wheels_section?]] – [[User:Flying_sheep|flying sheep]]<br />
<br />
== wpa_supplicant ==<br />
<br />
Regarding https://wiki.archlinux.org/index.php?title=WPA_supplicant&diff=577215&oldid=577167, one person ran into this problem in March of this year and spent too much time diagnosing it:<br />
<br />
https://bbs.archlinux.org/viewtopic.php?id=244950<br />
<br />
It took me a few days to find the problem. I want to make sure the next time someone encounters it, they easily find relevant information about what the cause is. Since you've reverted my edits to both netctl and wpa_supplicant, what do you suggest?<br />
<br />
--<br />
<br />
[[User:Pooryorick|Pooryorick]] ([[User talk:Pooryorick|talk]]) 08:24, 18 July 2019 (UTC)<br />
<br />
== F2FS and GRUB ==<br />
<br />
Hello. :) I'm here to address a recent disagreement. I noticed a reversion of my edit regarding the F2FS filesystem, in particular regarding the configuration file to edit (with you representing /boot/grub/grub.cfg and me representing /etc/default/grub). I run F2FS on my daily driver with an encrypted root filesystem and encrypted boot on a separate partition, and have never had to touch grub.cfg. I only automatically generate it. It's possible to use either, but /etc/default/grub would make more sense as a recommendation in my mind because grub.cfg has the potential to be overwritten during updates, whereas /etc/default/grub doesn't. <br />
<br />
If there's a compelling reason to use grub.cfg over /etc/default/grub, please let me know. ^^ I'm always eager to learn more about Arch. I don't want to get in a reversion war so I've left your change untouched for the time being.<br />
<br />
[[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 00:17, 8 September 2019 (UTC)<br />
<br />
:The reason is explained in the section: "If GRUB is used with an unsupported filesystem it is not able to extract the UUID of your drive so it uses classic non-persistent /dev/sdXx names instead." If it does not apply to F2FS, it should be made clear. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:29, 8 September 2019 (UTC)<br />
<br />
::You can specify UUID's in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, so my proposed solution would work for F2FS and other unsupported filesystems, without the burden of manually editing grub.cfg. If there's anything I need to clarify or something else I'm missing, just let me know. :) [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 19:37, 8 September 2019 (UTC)<br />
<br />
:::The {{ic|1=root=}} parameter is not supposed to be in GRUB_CMDLINE_LINUX_DEFAULT, regardless if UUID is used or not. ''grub-mkconfig'' automatically detects the root filesystem and adds the appropriate {{ic|1=root=}} parameter based on GRUB_DISABLE_LINUX_UUID. In any case, your change to the paragraph does not make sense. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:02, 8 September 2019 (UTC)<br />
<br />
::::It could simply be because I use full disk encryption, and adding a kernel parameter for the encrypted disk's UUID is correct in that situation. You're more experienced with contributing to the wiki, so I guess I'll defer to your judgment. It felt like a reasonable edit and solution to me and I don't see the downside to including it in GRUB_CMDLINE_LINUX_DEFAULT. [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 05:38, 9 September 2019 (UTC)<br />
<br />
== dracut executable link ==<br />
<br />
Hello, your last edit on the dracut page (https://wiki.archlinux.org/index.php?title=Dracut&oldid=596388) that undid my 'Link to direct "make executable" section for executable link' commit states: "the redirect executable points exactly to that section", but it doesn't. Following the [[executable]] link just points to the top of the Help:Reading page.<br />
<br />
{{unsigned|17:06, 28 January 2020|Krathalan}}<br />
<br />
:In that case your browser probably does not work correctly, because the redirect [https://wiki.archlinux.org/index.php?title=Executable&redirect=no really points to the section]. Or MediaWiki, there was a bug several years ago... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 28 January 2020 (UTC)<br />
<br />
:: How strange... thanks for pointing that out. It does indeed appear to be some issue with my Firefox configuration. [[User:Krathalan|Krathalan]] ([[User talk:Krathalan|talk]]) 19:51, 28 January 2020 (UTC)<br />
<br />
== Getting install.php work in DokuWiki ==<br />
<br />
Hi, than you for having undone my contribution and pointed to the right solution on [[Dokuwiki#Configuration]]. Indeed I had read this solution before, but I was misled by the condition "if you are using lighttpd or nginx and your PHP version is lower than 7": as I use Apache with php v. 7.4.3 I didn't take it into account. Do you know what a correct rephrasing could be? Maybe it should be deleted?<br />
<br />
Also, I think that, at the end of this same section, one should add something like "verify that {{Pkg|php-gd}} is installed and restart {{ic|php-fpm.service}}".<br />
<br />
Naturally I can do it myself, but I prefer to ask before.<br />
[[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 17:31, 19 February 2020 (UTC)<br />
<br />
:Hi, apparently it depends on whether you had {{ic|open_basedir}} set previously or not. I've changed the page, feel free to update the gd extension. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:16, 19 February 2020 (UTC)<br />
<br />
::Thank you! However, while, I didn't have {{ic|open_basedir}} set previously, I couldn't access ''install.php''. I suspect there is another thing to do, since the configuration editor in DokuWiki complains that it cannot modify the configuration files although ownership and permissions are correctly set for the relevant symlinks, directories and files, and so is {{ic|open_basedir}}. However I can edit my pages. Maybe a return from a new user with a fresh installation would be more useful, though. [[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 08:20, 20 February 2020 (UTC)<br />
<br />
== Dead link in Simple stateful firewall#See Also ==<br />
<br />
Hi, Jakub. I am about [https://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&diff=599725&oldid=599717 this] edit. I tried to follow that link one more time and it is not require entering captcha. I am not see any content limitations and my colleague (he uses Tor) does not see them too. I am not sure how it works, so I leave it on your descision. -- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 14:29, 1 March 2020 (UTC)<br />
<br />
:Well, maybe it depends on the location from which the request comes. But I don't know how it works either... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:33, 1 March 2020 (UTC)<br />
<br />
::my guess is it returns captcha for crawlers only -- [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 01:59, 2 March 2020 (UTC)<br />
<br />
:::I'm getting it in my browser... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 2 March 2020 (UTC)<br />
<br />
== SystemD user units depending on graphical session ==<br />
Hi,<br />
regarding reverting my addition to [[Systemd/User]], could you please explain why? I referenced [[https://www.freedesktop.org/software/systemd/man/systemd.special.html]] which directly contradicts what you said in your summary.<br />
<br />
{{unsigned|19:53, 5 May 2020|Fuero}}<br />
<br />
:The note in [[Systemd/User#How it works]] still applies - systemd services are never per-session, but per-user. The service does not magically get the correct DISPLAY or WAYLAND_DISPLAY variable, it does not work if you have multiple sessions per user, etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:45, 6 May 2020 (UTC)<br />
<br />
== Plymouth ==<br />
<br />
Actually with just Plymouth it does not work properly. Even 0dd17y had the same issue in https://bbs.archlinux.org/viewtopic.php?id=220900.<br />
<br />
The reason I did not file a bug report is that it is anyway fixed in the git version and the latest release (0.9.4) is around 2 years behind master<br />
<br />
{{unsigned|09:50, 6 May 2020|M.Srikanth}}<br />
<br />
:So if you don't have to file a bug report, add a full troubleshooting entry or at least properly reference your inline note instead of resorting to plain "if that does not work, try this instead". -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:15, 6 May 2020 (UTC)<br />
<br />
== [Bitcoin core] build the code and run the test suites ==<br />
<br />
Hello,<br />
<br />
This week, I managed to build the Bitcoin code and run all the test suites with the help of this page: https://jonatack.github.io/articles/how-to-compile-bitcoin-core-and-run-the-tests<br />
<br />
Archlinux has two particularities:<br />
* being in rolling release, it takes to manually use the library {{ic|Berkeley DB (BDB) v4.8}}<br />
* the {{ic|/tmp}} directory is by default limited to half the size of the Ram<br />
<br />
For these reason, maybe it could be interesting to have a page in the wiki to explain how to build the Bitcoin core?<br />
<br />
Cheers,<br />
<br />
Thomas<br />
<br />
[[User:Thomasb|Thomasb]] ([[User talk:Thomasb|talk]]) 20:29, 9 May 2020 (UTC)<br />
<br />
:I don't think that this is useful. There is the {{AUR|bitcoin-core-git}} package and nothing more should be needed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:53, 26 May 2020 (UTC)<br />
<br />
== Double linefeed results in extra line ==<br />
<br />
If you look at templates that end with double linefeed before noinclude this would result in extra line in resulting page.<br />
<br />
It may be a minor point but since you are perfectionist about wikitext I should mention this is a tradeoff and it results in slightly worse result.<br />
<br />
Removing just one linefeed removes the problem while still allowing it to not jumble all the tags into same line.<br />
<br />
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:30, 11 May 2020 (UTC)<br />
<br />
:If this is about [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=next&oldid=612179], the spaces I added back are not included when the template is used elsewhere, because the spaces are inside the noinclude tags. The extra space is only on the template page itself, but it does not result from template inclusion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:41, 11 May 2020 (UTC)<br />
<br />
::OFC, I mean the template page render has extra line. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 21:21, 11 May 2020 (UTC)<br />
<br />
:::I agree with [[User:Svito|Svito]], isn't it good to delete the extra blank lines? -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 05:39, 12 May 2020 (UTC)<br />
<br />
::::OK, let's do it. [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=616382&oldid=612181] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:47, 26 May 2020 (UTC)<br />
<br />
== Re: lighttpd: remove python2 version ==<br />
<br />
Instead of removing the example we could as well add an example using a Python3 library like https://pypi.org/project/flup6/.<br />
<br />
{{unsigned|15:23, 18 May 2020|Gruentee}}<br />
<br />
:Feel free to add it if you find it useful. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:56, 18 May 2020 (UTC)<br />
<br />
== Xbindkeys removal ==<br />
<br />
Hi, just wondering why you [https://wiki.archlinux.org/index.php?title=Xbindkeys&diff=617675&oldid=617670 removed my edit] from [[Xbindkeys]]? The xbindkeys page has a number of quick tips but no mention of how to bind anything to the Print Screen key so I thought it would be useful to add. -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 02:27, 3 June 2020 (UTC)<br />
<br />
:Giving examples for all keys on the keyboard is useless, there is [[Xbindkeys#Identifying keycodes]] which teaches how to find the keycodes and keysyms of any key. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 3 June 2020 (UTC)<br />
<br />
:: So how come you left the examples for the volume up/down and brightness? What is different between those examples and a screenshot example? Aren't more examples better to save people from hunting all over the place trying to piece things together themselves? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 14:03, 4 June 2020 (UTC)<br />
<br />
:::The difference is that when it comes to volume control, there are 1 or 2 options for the 99% most common cases, but for screenshot taking there are dozens of different options. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:15, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for edit to XDG Base Directory page regarding python_history ==<br />
<br />
I understand the justification for reverting the change I made, however I would like to point out that similar entries on the page (such as Maven) also have instructions for what contents to put in files (even though there is native documentation for those settings). Additionally, it took me a bit of re-reading on the linked Python documentation to reason out how the documentation's example needed to be modified, since it's not clear from the Python documentation whether placing such code in the PYTHONSTARTUP file will actually ''override'' the default behavior. [[User:Varriount|Varriount]] ([[User talk:Varriount|talk]]) 20:44, 20 June 2020 (UTC)<br />
<br />
:Even maven's note can be [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=631704&oldid=631630 shortened]. The notes in the table must be as short as possible, there is no place for extended explanations or long code snippets like in the upstream documentation. If the Python's documentation is not clear enough, I don't think any note in a massive convoluted table will ever be better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:47, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for Backlight page ==<br />
<br />
Hi, you reverted my change to [[Backlight]] page that mentioned WIP patches for controlling OLED panel brightness. I don't really understand justification for reverting it since currently the page says that OLED brightness can be controlled only by changing gamma ramp. That is wrong - since it's not the only way - these panels can control brightness with a PWM. Moreover controlling brightness with gamma ramp is not optimal - it essentially reduces dynamic range, i.e. at 50% you have 7 bits per pixel, at 25% - 6 bit per pixel, etc. That results in banding artifacts at lower brightness level.<br />
<br />
As far waiting for the patches to be merged before mentioning it there - it'll take ~3-6 months (yes, that's the process) and I haven't found *any* reference to these changes on the internet - everyone recommends using gamma ramp instead of fixing it properly. I'm absolutely sure that having information about these patches would not hurt [[User:Anarsoul|Anarsoul]] ([[User talk:Anarsoul|talk]]) 15:56, 30 June 2020 (UTC)<br />
<br />
:Linking to a repo which which has 2 custom commits on top of some arbitrary development version of the Linux kernel tree is not helpful for users. Nobody will compile directly from this repo which is already significantly outdated compared to recent kernel versions and there is no indication if the patches actually work with newer (or older) kernels. We can mention the PWM control as a general concept though. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:32, 12 August 2020 (UTC)<br />
<br />
== Automatic template correction ==<br />
<br />
Per [[Help:Template#Style]], templates should be used with the capitalization shown in the examples in their pages, so {{ic|&#123;{AUR&#124;...}} is correct, while {{ic|&#123;{aur&#124;...}} is not.<br />
<br />
However, there are pages that don't respect that rule (e.g. [[Android_Debug_Bridge]] until recently).<br />
<br />
I beleive this correction should be easy to implement using a bot. What do you think?<br />
<br />
{{unsigned|07:24, 25 August 2020|Relrel}}<br />
<br />
:Yes, this should be easy, but the bot should not make a huge amount of simple style-only changes - they should be combined with corrections for more complex rules. Anyway, there is an idea to create a [https://github.com/lahwaacz/wiki-scripts/issues/22 style linter] for the ArchWiki rules. Would you like to help? ;-) – [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:21, 25 August 2020 (UTC)<br />
<br />
== Failed to create tun device ==<br />
<br />
I don't understand your reason for [[https://wiki.archlinux.org/index.php?title=NetworkManager&diff=0&oldid=634880 removing my section in NetworkManager]]. Could you elaborate?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 07:40, 11 September 2020 (UTC)<br />
<br />
:You can't use [[systemd-networkd]] and [[NetworkManager]] at the same time. Even if you don't have any ''.network'' file for systemd-networkd, you can't solve NetworkManager's problems with systemd-networkd. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:43, 11 September 2020 (UTC)<br />
<br />
::Ok, thanks, in this case it solved the error I got. Now the VPN works. Do you have an idea about how to solve it without systemd-networkd?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 22:27, 11 September 2020 (UTC)<br />
<br />
:::You should really fix the permission problem for {{Pkg|networkmanager-openvpn}}. The tun interface should be managed by OpenVPN which needs rights to create it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 12 September 2020 (UTC)<br />
<br />
::I don't think this statement is entirely correct. [[systemd-networkd]] and [[NetworkManager]] can happily co-exist together if they are managing different interfaces. I unfortunately don't have a reference to point to this, but I came across this being mentioned a couple of times on forums. I personally use [[NetworkManager]] on my laptop to handle wifi, while [[systemd-networkd]] is in control of virtual ethernet and bridges for all my [[systemd-nspawn]] instances. [[User:Romstor|Romstor]] ([[User talk:Romstor|talk]]) 03:24, 12 September 2020 (UTC)<br />
<br />
== [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&oldid=636526/ XDG Base Directory]: Undo revision 636525 ==<br />
<br />
Dear Lahwaacz,<br />
<br />
maybe my changes were to rushed and from my point of view only. But I have two points to consider:<br />
<br />
# If I put the quotes around my vimrc and source it from my .bash_profile, I get the vim-error E471 (Argument required). Without quotes, this doesn't happen. So this change based on experience.<br />
# The rtp should includes directories, which are needed at runtime. (in plain vim e.g. ~/.vim). This is not a typical configuration directory. My mistake was, that I supposed that everyone put their vim plug-ins in $XDG_DATA_HOME and not in $XDG_CONFIG_HOME, because from my point of view a plug-in doesn't belong to the configuration. Maybe it is a good idea to add a remark, which explains the addition of $XDG_CONFIG_HOME to the rtp.<br />
<br />
[[User:Grrr|Grrr]] ([[User talk:Grrr|talk]]) 13:53, 26 September 2020 (UTC)<br />
<br />
# Quotes are there because $XDG_CONFIG_HOME may contain spaces.<br />
# It's not only about quotes - the runtimepath has subdirectories for color schemes, keymaps, autoload scripts etc.<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 26 September 2020 (UTC)<br />
<br />
== Readability in Wiki ==<br />
<br />
I noticed that you and the other admins and moderators often want sentences to continue endlessly, without line breaks.<br />
For example in the introduction of [[Wayland]].<br />
<br />
I think it would be better to have more seperated sentences, so it is easier to read and "important" information is easier visible for people.<br />
I don't know who is responsible, but maybe some options in MediaWiki (or whatever this wiki software is) could be changed as well, to make make line breaks etc. easier and reduce the height-space (if you know what I mean) between sentences, so it looks better, even though line breaks are used.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:38, 15 October 2020 (UTC) G3ro<br />
<br />
:I don't know exactly what you mean. Is it about the readability of the rendered HTML or the "source code" of the page? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:15, 15 October 2020 (UTC)<br />
<br />
:: Well I guess it can be about both. But mainly it is about what people see on the page.<br />
:: There are three seperate topics I mentioned:<br />
<br />
:: 1. Use line breaks: I would like to use more line breaks, because if you have long sentences that are written after each other without line breaks, it gets "harder" to recognize when the next sentence starts.<br />
:: While I agree to what you said somewhere, that sentences that belong directly together, should be written in one "paragraph", it would be useful for sentences that cover (slightly) different "topics" to be visibly parted.<br />
<br />
:: 2. Adjust margin options: I notice that when line breaks are used, there is a vertical space added between two sentences. Just like in this post. If you would use line breaks more often, this is a little too much spacing in my oppinion.<br />
<br />
:: 3. Potential options to make line breaks easier: It would be very convenient if a line break in the source code would lead to a line break in displayed text as well, instead of needing to add an empty line.<br />
<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:33, 15 October 2020 (UTC) G3ro<br />
<br />
:::OK, now I understand. I agree that splitting different topics usually improves legibility, but they should be split into separate paragraphs and not just by line breaks (e.g. using the &lt;br> tags). Paragraphs are semantic units whereas line breaks inside a paragraph are usually typographic errors.<br />
:::Also note that such splitting alone may not be enough to improve the text flow. For example, if we consider the intro for [[Wayland]], the second sentence about XWayland would not constitute a good paragraph - it is just a plain statement and the new topic is not nicely introduced. Ideally, you'd split the topic and make some wording changes for the second paragraph.<br />
:::As for the margin options, that is the difference between paragraph splitting and non-semantic line breaks. In my opinion, the styling is correct in this respect, as paragraphs should be discernible. You mentioned that you like line breaks to easily recognize where a sentence ends - but reading should be based on whole paragraphs, not sentences. There should be no reason to skip anything in the middle of a paragraph, otherwise it should be probably split into multiple paragraphs or otherwise rephrased.<br />
:::If you find it hard to follow a long sentence horizontally on a wide screen, we might consider enforcing some maximum width for the whole content. I think the readability would be better, since there would be more top-to-bottom eye movement at the cost of left-to-right-and-back.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:59, 15 October 2020 (UTC)<br />
<br />
== Xorg parentheses ==<br />
<br />
I actually think that X(org) is very useful to imply that it is one and the same thing.<br />
<br />
It might even be more confusing now, as we use both Xorg and X, because the wiki title and the package titles are Xorg.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:30, 17 October 2020 (UTC) G3ro<br />
<br />
:Well the conventions should be established on the [[Xorg]] page, not anywhere else... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:36, 17 October 2020 (UTC)<br />
<br />
:: Imo the conventions are established by upstream and they use a wide variety of X, X.org, X(org), Xorg etc.<br />
:: As I said I always prefer X(org) because then it is clear, that both are same thing.<br />
:: But ultimately it's your decision. <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:43, 17 October 2020 (UTC) G3ro<br />
<br />
:::When upstream is not capable of making a unambiguous decision, it makes sense that other projects pick some option and stick with it wherever they can to keep at least some consistency. So for this wiki, pages should use the same style as the [[Xorg]] page. But feel free to start a discussion about this in [[Talk:Xorg]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:56, 17 October 2020 (UTC)<br />
<br />
== SSHFS - systemd edit ==<br />
<br />
The edit was removed because "there is no advantage over using fstab entries".<br />
<br />
Is not only about the dis/advantages of the systemd option, is about that it is another possibility to achieve the task, that is why it was created in another level and the fstab section was left alone.<br />
<br />
Reconsider the edit as it presents another option which people can use.<br />
<br />
[[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 16:22, 22 October 2020 (UTC)<br />
<br />
:There is no need to use anything else, fstab just works well enough. Configuring mounts with systemd services is not a good idea - it is much more bloated than fstab and not the right tool for it. If anything, a different type of systemd units should be used: {{man|5|systemd.mount}}. But creating the mount units manually is still pretty useless since everything can be configured in fstab and systemd will generate the unit for you. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:22, 22 October 2020 (UTC)<br />
<br />
:: It is about the ability to use the user's .config file and all the proper options that are saved there. Also systemd gives the possibility to use different targets, so the user could mount it when an specific user logs in or when a graphical session starts. I could argue that bad a modification of fstab could lead to a system that doesnt boot, but such poorly configured systemd unit file just fails and the system is fine. Just give the user the information and let it decide what they can use depending on their use case. [[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 08:08, 24 October 2020 (UTC)<br />
<br />
:::You can configure systemd targets in fstab using the {{ic|x-systemd.wanted-by}} and {{ic|x-systemd.required-by}} options, there are also {{ic|nofail}} and {{ic|noauto}} options. Please read the {{man|5|systemd.mount}} manual.<br />
:::Using hosts from the user's {{ic|.ssh/config}} is the only thing which is not possible with fstab, but this does not warrant using the wrong tool for the task. Simple copy the full {{ic|user@hostname}} into fstab and you're done.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:47, 24 October 2020 (UTC)<br />
<br />
== [[Self-encrypting drives]] ==<br />
<br />
Hi, I'd like to respectfully disagree with the rollback. It's specific to sedutil that with most commands you need to input /dev/nvme0 (when encrypting the device) but for the sleep commands it requires /dev/nvme0n1 or it fails with a very unspecific error (Error saving the password to the kernel errno = 25), as found out in the discussion https://github.com/Drive-Trust-Alliance/sedutil/issues/90<br />
<br />
All in all I believe that it is important to keep this piece of information which was found out in a long discussion between the reporter and the developers. I ran into it and I believe many people may run into it, considering most of the new SSD will be NVMe. Best, [[User:Przemub|Przemub]] ([[User talk:Przemub|talk]]) 13:34, 28 October 2020 (UTC)<br />
<br />
:OK, then it makes sense. But it should be probably explained before, not in the section about the sleep command. Also please add the link to the note as a reference. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:27, 28 October 2020 (UTC)<br />
<br />
== Nvidia Installation ==<br />
<br />
The whole guide is unnecessary long and overcomplicated formulated.<br />
Shorter is better, most people will know their graphic card for example, so the determination etc. is only optional.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:21, 10 November 2020 (UTC) G3ro<br />
<br />
:Moving some info to some other page and leaving a tip behind does not make it shorter, but harder to follow. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:36, 10 November 2020 (UTC)<br />
<br />
== Btrfs layout ==<br />
<br />
Hi, Lahwaacz<br />
<br />
Thanks for maintaining [[Snapper]]! However I think the layout is not openSUSE specific and beneficial to all btrfs users. Can you elaborate your reason of undoing the edits? IMO the previous 'simple layout' complicates the rollback procedure.<br />
<br />
Cheers,<br />
[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 07:26, 3 December 2020 (UTC)<br />
<br />
:It is not overcomplicated, it is just doing things right. You can read about that in the forum thread, see the first note in [[Snapper#Suggested filesystem layout]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:24, 3 December 2020 (UTC)<br />
<br />
::Anyway I've moved the guides to my user page. It's not that I haven't read the 5-year-old forum post, it's that before the current layout I followed that post and resulted in a not fully rolled-back system. That post also sourced (then current) information from openSUSE. openSUSE has since massively overhauled the layout, as I pointed out in an edit you undid earlier.[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 09:02, 3 December 2020 (UTC)<br />
<br />
::Since last message I've extensively documented the new layout at [[User:I2Oc9/Btrfs_subvolumes]] and [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption]]. Have a look for yourself. Nothing new really, but IMO [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my take]] is much more simpler and complete than the supposedly [[Snapper#Restoring_/_to_a_previous_snapshot_of_@|simpler one]]. That one does not leverage native {{ic|snapper rollback}} or {{Pkg|grub-btrfs}}, among other things. I strongly suggest you try if you have time. [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 11:55, 3 December 2020 (UTC)<br />
<br />
::Actually if you look closely, none of [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my recovery methods]] is specific to [[User:I2Oc9/Btrfs_subvolumes#A_new_kind_of_layout|the new 'complex' layout]], it will work totally fine with the old one. I just don't think moving @ around in live environment is appropriate.<br />
<br />
::On the other hand, the layout recommendation has been updated by openSUSE [https://en.opensuse.org/SDB:BTRFS], why stick with the old one? [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 12:37, 3 December 2020 (UTC)<br />
<br />
:::The main reasons why I reverted your edits on the [[Snapper]] page are: 1) it was a huge change which was not discussed previously as required by [[ArchWiki:Contributing#The 3 fundamental rules]], and 2) it has some elements which do not apply to Arch (see below). If you wish to propose a better layout of the subvolumes, it should be discussed in [[Talk:Snapper]] first. Your user pages would serve as great drafts.<br />
:::Note that the current suggested layout is not ''flat'' in the sense of [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|your section]] - it has a separate subvolume for {{ic|.snapshots}} so it does not lead to the recursive mess. So your proposed layout seemed very similar to the current suggested layout. The real difference is which subvolume gets mounted at {{ic|/}}, but I did not find it explained anywhere on the Snapper page before I reverted the changes (I get it now from your user page). I also did not find a proper documentation of the openSUSE's layout - it seems to be just the product of their installer and the documentation only deals with the result, saying at most that [https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-snapper.html#sec-snapper-snapshot-boot the subvolume configuration must not be changed] for rollbacks to work.<br />
:::Now the openSUSE-specific elements: some Arch packages actually install software into {{ic|/opt}}, so the recommended layout should not suggest a separate subvolume for this path. Even more importantly, the pacman database is located at {{ic|/var/lib/pacman/local/}} and it must be rolled back along with the system, so there should be no separate subvolume for {{ic|/var}}. Instead, users should be encouraged to create (even nested) subvolumes for specific data directories under {{ic|/var}}, such as {{ic|/var/log}}, {{ic|/var/tmp}}, {{ic|/var/cache/pacman}}, {{ic|/var/lib/machines}}, etc.<br />
:::Finally, the suggested layout should not be GRUB-specific, there should be no recommendations regarding a boot loader. Sure it is useful to include non-trivial tips, but people may actually use a different boot loader.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:31, 4 December 2020 (UTC)<br />
<br />
::::Thanks for your detailed reply. I admit that I'm not knowledgeable on the intricate differences between distributions and shouldn't have made the changes without properly discussing them first.<br />
::::Yes, I get that the current layout is not [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|the one described in this section]] and indeed properly separates {{ic|/.snapshot}} and {{ic|/}}. The layout I proposed attempts to add some "niceties" such as supporting multi-distribution installations (complex and unnecessary, I agree) and bring the openSUSE layout here, which is a mistake, as you've pointed out.<br />
::::As for GRUB, since I use LUKS all the time and it's the only bootloader supporting encrypted {{ic|/boot}} on Btrfs on LUKS1, I really didn't think of any other possibilities.<br />
::::I will incorporate your recommendations to my user page and add a new section in [[Talk:Snapper]] pointing to those pages.<br />
::::Cheers -- [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:09, 4 December 2020 (UTC)<br />
<br />
:::::I've adopted [[Install_Arch_Linux_on_ZFS#System_datasets|Archlinux Root on ZFS layout]] to [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Create_subvolumes|my proposal]]. [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:56, 4 December 2020 (UTC)<br />
<br />
== Reflector Revert ==<br />
<br />
Hi Lahwaacz, about your [https://wiki.archlinux.org/index.php?title=Reflector&oldid=643749 revert], it seems like there's precedence for including AUR packages that replicate the code on the wiki. For example, in [[dash#Relinking /bin/sh]].<br />
<br />
In addition, I believe that there's value for linking the AUR package because it allows a simpler user experience where the AUR package is maintained for them. That way, if it is ever updated, they can easily fetch the update instead of religiously checking the wiki page (which most users probably don't do).<br />
<br />
Thanks!<br />
<br />
[[User:Denton-l|Denton-l]] ([[User talk:Denton-l|talk]]) 01:52, 7 December 2020 (UTC)<br />
<br />
:That precedence was only created by [https://wiki.archlinux.org/index.php?title=Dash&type=revision&diff=561587&oldid=518398 yourself]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 5 May 2021 (UTC)<br />
<br />
== firefox zoom ==<br />
<br />
"no reason to zoom manually, see HiDPI)" - fractional scaling doesn't work [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 26 December 2020 (UTC)<br />
<br />
:That should be explained in [[HiDPI#Firefox]] anyway. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:48, 26 December 2020 (UTC)<br />
<br />
::it's good to have this mentioned somewhere clearly so people know about it before they say "fonts on linux suck" [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 15:51, 29 December 2020 (UTC)<br />
<br />
== Intel GVT-g edits ==<br />
<br />
Hello Lahwaacz,<br />
<br />
I have noticed that you reverted one of the edits I have performed on [[Intel_GVT-g]].<br />
<br />
About this revert: [https://wiki.archlinux.org/index.php?title=Intel_GVT-g&oldid=648062 Windows problems are out of scope]<br />
<br />
While I understand that the ArchWiki is about ArchLinux, this article in particular mentions Windows in the introduction, and already includes another troubleshooting point about Windows. The issue I have encountered with the black bars is somewhat common, as I have found other people discussing it online, and I really fail to see why not including this piece of information in this article would be better than including it.<br />
<br />
Please, let me know your thoughts. If you think that the point can be improved, I will be happy to do that.<br />
<br />
Ciao,<br />
<br />
[[User:Wilcomir|Wilcomir]] ([[User talk:Wilcomir|talk]]) 09:14, 3 January 2021 (UTC)<br />
<br />
:Well, the existing section about a Windows problem is actually solved by configuring the Linux host. I think anything involving configuration or installation of programs in Windows is not appropriate for long troubleshooting sections. At most, they could be mentioned in a short reference to other sites which describe the problem in detail. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:34, 3 January 2021 (UTC)<br />
<br />
== <s>XDG configuration for Vim</s> ==<br />
<br />
Hi Lahwaacz,<br />
<br />
You have reverted the updated Notes for Vim on [[XDG Base Directory]], because "copy-pasted from a blog post".<br />
<br />
The problem is, not only is the configuration presented currently also copied from a blog post too, but is already 10 years old.<br />
<br />
Would it be OK, if we bring back the more up to date version? Or at least remove the obsolete one and leave link to newer?<br><br />
(Although I think a copy on wiki would be beneficial in case my blog ceases to exist)<br />
<br />
[[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 02:05, 12 January 2021 (UTC)<br />
<br />
:OK let's close this. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:49, 29 August 2021 (UTC)<br />
<br />
== Root on ZFS draft ==<br />
<br />
Hi, I submitted [https://github.com/openzfs/openzfs-docs/pull/104 a Root on ZFS draft] to official doc repo.<br />
<br />
In the draft, the following directories are separated from root filesystem:<br />
home,root,srv,usr/local,var/log,var/spool,var/tmp<br />
<br />
Is this appropriate for Arch Linux? Or do you have any suggestion on the draft?<br />
Any comment is appreciated.<br />
[[User:M0p|M0p]] ([[User talk:M0p|talk]]) 01:28, 23 January 2021 (UTC)<br />
<br />
== Re: undo GRUB - Common installation errors ==<br />
<br />
Concerning your undo of [https://wiki.archlinux.org/index.php?title=GRUB&diff=next&oldid=649799 Add the error message `Could not prepare Boot variable: No space left on device`)]<br />
Is there a better place to for this Information? One can find the solution in various forums, but I thought it could be helpful to have it in this wiki somewhere. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 12:51, 25 January 2021 (UTC)<br />
<br />
:The error message is not specific to the {{ic|/sys/fs/pstore/}} filesystem (which does not even seem to be used by default on Arch...) Where did you find that? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:16, 25 January 2021 (UTC)<br />
<br />
::I did not find anything Arch specific, but this post about Debian helped: [https://donjajo.com/fix-grub-efibootmgr-not-set-variable-no-space-left-device/ Post]. I also found something about [https://askubuntu.com/questions/1072618/could-not-prepare-boot-variable-no-space-left-on-device-grub-install-error-ef /sys/fs/efi/efivars/dump-*] The problem is that the actual efi-partition does not seam to be the problem, there is more than 70% space left. If there is better information to guide the user in the right direction that wuld be more helpful. This is what I found worked, but I admit that I don't know much about how grub operates. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 16:20, 25 January 2021 (UTC)<br />
<br />
:::This wiki ''is'' Arch specific so old posts about Debian or Ubuntu do not apply. Even if they did, this is hardly a ''common'' installation problem. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:29, 26 January 2021 (UTC)<br />
<br />
::::I know that, and would not have put it there if it didn't occur on my Arch Linux installation. If this is something that should not be documented in this wiki, I understand that. Is there any other place you would recommend? An issue for grub-install maybe? [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 22:24, 26 January 2021 (UTC)<br />
<br />
== Kernel Compilation time ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Kernel&diff=next&oldid=650896 link]<br />
<br />
I don't think we should judge information by what is obvious to experts.<br />
People might have experience with compilation of other programs, which mostly is fast, and then there is the kernel which takes forever to compile.<br />
I think it does not hurt anyone to make people aware of it.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:03, 6 February 2021 (UTC)<br />
<br />
:It is an unnecessary information without a definite answer which can even be [https://html.duckduckgo.com/html?q=how%20long%20does%20it%20take%20to%20compile%20Linux%20kernel searched elsewhere]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:23, 6 February 2021 (UTC)<br />
<br />
:: I disagree, with that argument nearly any tip and note is unnecessary. These things are intended to inform users about things that should be taken into consideration and that are different from the norm.<br />
:: Also do you search for the compilation time for every program you intend to compile? I don't.<br />
:: Furthermore this info is included, why not tell it to people directly on the start, so they don't read over it? <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:36, 6 February 2021 (UTC)<br />
<br />
:::If someone wants to compile the Linux kernel, they should obviously expect that it will take ''some time''. Stating that it "can take up to several hours" does not make sense without referring to a specific hardware. Obviously, it will take much longer on a poor laptop than on a powerful workstation with a many-core processor, but people can assume that themselves. Without a reference to a specific hardware, the note is unnecessarily discouraging because the compilation can be as fast as some tens of minutes - it is by far not the most expensive package to compile...<br />
:::As you said, people can find better notes later along with advices to enable parallel build etc. which is all that's needed IMO.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:03, 6 February 2021 (UTC)<br />
<br />
== Wayland style ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Wayland&diff=prev&oldid=650979 link]<br />
<br />
I think in the old version it was much easier to read the "source code", so I don't see why there can't be spaces between it.<br />
Things shouldn't be complicated more than necessary.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:11, 6 February 2021 (UTC)<br />
<br />
:Most templates on the wiki are written without spaces around the |. When we [https://github.com/archlinux/archwiki/pull/32 switch the editor], there will even be syntax highlighting. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:25, 6 February 2021 (UTC)<br />
<br />
== Bluetooth keyboard ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php/Bluetooth_keyboard link]<br />
<br />
On your last change you said "not specific to keyboards, all of this is already mentioned on the Bluetooth page", the point is that this is extremely relevant for bluetooth keyboard since it is required to perform the login! If this little piece cannot be duplicated I would suggest at least to leave a link saying "If you want to autoconnect at boot please refer to...". I'm new here and I would not touch it further, but please evaluate the suggestion (this is because after reading bluetooth keyboard page and not finding the solution I had to look for it on forums)<br />
<br />
{{unsigned|21:17, 20 February 2021|Stevexyz}}<br />
<br />
:Well, basically the whole page is flagged to be merged with the main [[Bluetooth]] page, so it's expected to be incomplete. Other tips may always be found on a more general page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:40, 21 February 2021 (UTC)<br />
<br />
== Re: Steam Needs to be online error ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Steam/Troubleshooting&diff=next&oldid=653073 link]<br />
<br />
The problem here is that DNS resolution in general works already (yes even outside browsers), i.e. <br />
<br />
dig media.steampowered.com<br />
<br />
would run successfully, but the Steam client couldn’t resolve it. The DNS request from 'dig' shows up in my nameserver’s log, the one Steam should send doesn’t. This indicates it might indeed a problem specific to Steam, and it’s not as easy as just say "go fix your DNS resolution", as it already may work correctly for everything but Steam.<br />
<br />
Additionally, at no point does [[Domain name resolution]] even mention nscd, so you effectively removed a fix/workaround for the problem from the Wiki. So I was definitely not "duplicating an article" here. [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 08:12, 22 February 2021 (UTC)<br />
<br />
:Could I please hear your opinion on this? I’d be happy to just add something along the lines of "if you made sure DNS resolution works but Steam still can’t resolve it, try additionally enabling the nscd service" to the Steam troubleshooting page. Unfortounately I don’t know why running the service helps, but I’d still like to give others an easier time finding this solution than I had myself. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 09:15, 28 February 2021 (UTC)<br />
<br />
::Hi, I'm sorry for the delay. Could you test if using a different program for DNS caching (e.g. [[systemd-resolved]]) instead of {{ic|nscd.service}} fixes the problem? If not, then it's probably not due to DNS - {{man|8|nscd}} actually caches more than just DNS. Also if you have a reference to some website where you found about nscd, it would be nice to add it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 28 February 2021 (UTC)<br />
<br />
:::No worries. Using [[systemd-resolved]] for DNS resolution (and caching I guess, I wasn’t aware it does that, too) was a thing I did try, but that didn’t fix it for me. The place I found out about nscd fixing it was actually the [https://bbs.archlinux.org/viewtopic.php?id=263356 Arch forums]. When I search the web for Steam in combination with nscd, all I can seem to find are more forum entries of people that don’t know why that fixes it either. I can try a bit to find out what nscd does to make it work, but I’m not too confident I will be successful. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 14:51, 28 February 2021 (UTC)<br />
<br />
::::Okay, so {{ic|nscd}} allows to [https://man7.org/linux/man-pages/man5/nscd.conf.5.html dis-/enable caching per service], and it’s indeed enabling it for {{ic|hosts}} that makes it work. That’s weird though, since [[systemd-resolved]] has caching enabled by default, and using it for resolution didn’t make {{ic|steam}} work for me. Leads me to think that I didn’t set it up correctly, although resolving via {{ic|dig}} *did* work. Since [[steam]] depends on [[Name Service Switch]], I tried resolving using {{ic|getent}} manually with nscd disabled, but that worked while steam did not. I’m not really sure what to make of this, since I have no idea how this low level networking/resolving stuff works really. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 15:39, 28 February 2021 (UTC)<br />
<br />
:::::Hmm, I don't know the details either. Steam needs the multilib packages so maybe that's part of the problem. Could you add your findings to the section and use [[Template:Expansion]] for the missing details? Maybe someone can figure it out. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:44, 28 February 2021 (UTC)<br />
<br />
::::::Sure, I can do that. I’ll probably need a minute to figure out how to use the template though, but I should have the time later today. Thanks for your input on this. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 17:56, 28 February 2021 (UTC)<br />
<br />
== Removal of website link ==<br />
<br />
Refers to this: https://wiki.archlinux.org/index.php?title=PipeWire&diff=next&oldid=653701<br />
<br />
I don't understand why that has to be removed. The official website should be always worth a mention, even if it is somehow mentioned in the text already.<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:02, 28 February 2021 (UTC)<br />
<br />
:The "See also" section is for additional links, it is not intended as a collection of all links used on a page. Adding links which are clearly mentioned in the appropriate place only clutters the list. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:24, 28 February 2021 (UTC)<br />
<br />
:: There are just three links and only one of them is really useful, the others could maybe even be removed as they link to old blog posts.<br />
:: I can only repeat myself, that things don't always have to be made more complicated than necessary.<br />
:: The official website is a central point which links to many more useful ressources, so it's one link for much information.<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:34, 28 February 2021 (UTC)<br />
<br />
== Removal of bootia32.efi generation procedure from X205TA install page. ==<br />
<br />
Those [https://wiki.archlinux.org/index.php?title=ASUS_x205ta&diff=596239&oldid=562734 instructions] were really straightforward and useful, imho in comparison present ones require too much material to be confident with. I think it's (paradoxically) way easier to generate the file than to configure a `grub.cfg` from zero to boot a live cd. Can we undo the edit? Otherwise we could put them in a new page or section in the GRUB page and link to them maybe. [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 05:07, 4 March 2021 (UTC)<br />
<br />
:If there is something wrong with the information on the [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Booting_64-bit_kernel_on_32-bit_UEFI general page], it should be improved instead of describing the same procedure in a different way on a completely unrelated page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:16, 6 March 2021 (UTC)<br />
<br />
:: I didn't know we had that info in the UEFI article. I think it could be appropriate to insert the [https://en.wikipedia.org/wiki/Template:See_also#Examples See also] archwiki equivalent (which I couldn't find) for UEFI page on top of the aforementioned section, what do you think? [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 13:28, 7 March 2021 (UTC)<br />
<br />
:::Well, the removed section was previously flagged with "Duplicates [[Unified Extensible Firmware Interface#Booting 64-bit kernel on 32-bit UEFI]]"...<br />
:::Also the laptops pages are usually related to most of the general pages on this wiki, adding all of them would be pretty useless. Users should not expect to find everything on a single laptop page, they should always check if there is a general page for their topic with more details.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:58, 7 March 2021 (UTC)<br />
<br />
== Re: Show how to use systemd/Timers with wg-quick@.service ==<br />
<br />
I don't think using service is the appropriate when you want to start Wireguard at boot. For most people connecting to a VPN is not exactly part system startup.<br />
A timer should more appropriate.<br />
[[User:ENV25|ENV25]] ([[User talk:ENV25|talk]]) 10:03, 11 April 2021 (UTC)<br />
<br />
:I don't see how OnBootSec=1min is more appropriate than an automatically starting service. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:19, 11 April 2021 (UTC)<br />
<br />
== USB flash installation medium (BIOS bootable) ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=next&oldid=673926 revert]: "making the partition bootable is discussed below"<br />
Do you mean installing syslinux and `dd` the [gpt]mbr with "discussed below"? This was not enought for my setup (Sandisk Ultra 64GB, Dell XPS 9370) to make the partition BIOS bootable. It did work right after I checked "Legacy BIOS Bootable" checkbox using gnome-disks.<br />
<br />
{{Unsigned|13:42, 30 May 2021 (UTC)|Auipga}}<br />
<br />
:Yes, that's what I meant. If it does not work, it should be fixed rather than providing a duplicate instruction without a reason. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:16, 30 May 2021 (UTC)<br />
<br />
== Systemd-networkd systemd-networkd-wait-online.service discussion modifications ==<br />
<br />
I'm not sure why you're reverting my edits.<br />
<br />
You said: "''empty ExecStart is explained in Systemd#Examples''"<br />
<br />
Exactly: Systemd#Examples clearly states "''As another example, in order to replace the ExecStart directive for a unit that is '''not of type oneshot'''''"<br />
<br />
'''systemd-networkd-wait-online''' is a oneshot service. By having the superfluous empty ExecStart you're just confusing people.<br />
<br />
Regarding the file naming, yes the name is irrelevant, but it's generally helpful to non-expert users to stick to canonical naming conventions.<br />
<br />
Please make sure you're on solid ground before reverting edits; you're just discouraging people from engaging with the Wiki. Thanks. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 16:51, 9 June 2021 (UTC)<br />
<br />
:{{man|5|systemd.service}} says: "Unless Type= is oneshot, exactly one command must be given. When Type=oneshot is used, zero or more commands may be specified."<br />
:So when a service is not oneshot, users ''must'' clear ExecStart before adding a modified command in the drop-in file. If a service is oneshot, they ''may or may not'' clear ExecStart, since the service may have multiple ExecStart commands.<br />
:In case of systemd-networkd-wait-online, I don't see why you would want to run multiple instances with different options: one to wait for ''all'' links (which is the default command) and another one to wait for ''any'' link (which is the command in the drop-in example). So clearing ExecStart really makes sense for systemd-networkd-wait-online.<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:44, 9 June 2021 (UTC)<br />
<br />
== Pacman: Install missing dependencies ==<br />
<br />
Hi. [https://wiki.archlinux.org/index.php?title=Pacman&type=revision&diff=690774&oldid=690762 "Pacman" Revision as of 21:50, 4 August 2021 (undo)] - maybe at least put that into [[System_maintenance#Avoid_certain_pacman_commands]]?<br />
<br />
[[User:Galeksandrp|Galeksandrp]] ([[User talk:Galeksandrp|talk]])<br />
<br />
:[[System_maintenance#Avoid_certain_pacman_commands]] already mentions {{ic|-Rdd}}. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:12, 14 August 2021 (UTC)<br />
<br />
== DPMS: "\033[9;0]" ==<br />
<br />
Hi. It seems that you removed {{ic|echo -ne "\033[9;0]"}} from [[Display Power Management Signaling|DPMS]]<br />
<br />
https://wiki.archlinux.org/index.php?title=Display_Power_Management_Signaling&diff=629705&oldid=625073<br />
<br />
[https://www.denx.de/wiki/view/DULG/SwitchOffScreenSaverAndBlinkingCursor A DULG page] and [https://unix.stackexchange.com/a/23636 a U&L post] brought me here.<br />
<br />
May I ask (1) if this method is still working; and (2) where is this escape sequence documented? [not found in {{man|4|console_codes}}]<br />
<br />
Thanks.<br />
<br />
{{Unsigned|05:23, 15 August 2021 (UTC)|PXf}}<br />
<br />
:[[Display Power Management Signaling#DPMS interaction in a Linux console with setterm]] says that setterm works by writing escape codes to the terminal device. The first subsection shows how to reverse-engineer the escape codes. Note that the escape codes are an implementation detail that users should not be concerned with, their documentation is certainly not our job. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:40, 15 August 2021 (UTC)<br />
<br />
== Linux console/Keyboard configuration ==<br />
<br />
Hi, you recently reverted my edit https://wiki.archlinux.org/index.php?title=Linux_console/Keyboard_configuration&oldid=693887. The reason I made that edit, was that I used to put my custom keymap in {{ic|/usr/local/share/kbd/keymaps/personal}} per the previous version of the wiki page. But this doesn't work with ''sd-vconsole'', as it's include files don't get loaded. Your suggested workaround by adding all required files using [[mkinitcpio#BINARIES and FILES|mkinitcpio BINARIES and FILES]] is rather tedious, as all the include files need to be in there, added by hand. This is done automatically by ''sd-vconsole'' if the file was put in {{ic|/usr/share/kbd/keymaps/}}. The reason I made this edit is due to https://bugs.archlinux.org/task/71788. See Giancarlo Razzolini's comment. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:43, 2 September 2021 (UTC)<br />
<br />
:It's just one custom file under {{ic|/usr/local}} and one entry in {{ic|FILES}}. What is so tedious about it? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:37, 2 September 2021 (UTC)<br />
<br />
:: It's not just one file. All the dependencies need to be included too under {{ic|/usr/share/kbd/keymaps/}}. There are quite a few in my case, when I just include ''us.map'' to modify it slightly. See the ''sd-vconsole'' hook script. That script has a part where it finds all the dependencies of a keymap.<br />
<br />
:: * ''/usr/share/kbd/keymaps/i386/include/compose.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/euro1.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-keys-bare.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-with-alt-and-altgr.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/qwerty-layout.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/personal.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/us.map''<br />
:: * ''/usr/share/kbd/keymaps/include/compose.latin1''<br />
<br />
:: [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 12:01, 2 September 2021 (UTC)<br />
<br />
::: I moved this to the talk page so I remember it and others can discuss too. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:18, 4 September 2021 (UTC)<br />
<br />
::: Oh, I see. In that case I suggest we add a tip like this:<br />
::: {{Tip|If you use the {{ic|sd-vconsole}} [[mkinitcpio#Common hooks|mkinitcpio hook]] instead of {{ic|keymap}}, keymaps located under {{ic|/usr/local}} as well as their dependencies from {{ic|/usr/share/kbd/keymaps}} need to be manually specified in the {{ic|FILES}} array in {{ic|mkinitcpio.conf}}. On the other hand, custom files located in {{ic|/usr/share/kbd/keymaps}} will be added automatically when configured in {{ic|/etc/vconsole.conf}}.}}<br />
::: Because this is relevant only for people using the {{ic|sd-vconsole}} hook and otherwise it does not make sense to pollute {{ic|/usr/share/kbd/keymaps}} with custom files.<br />
::: — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:55, 5 September 2021 (UTC)<br />
<br />
== cow_* ==<br />
<br />
Hi Lahwaacz. About the [https://wiki.archlinux.org/index.php?title=Archiso&diff=next&oldid=692981 how/why issue] (there will be no more &lt;!-- --&gt;). What if, for once, that I want to install some large packages after booting archiso, and would not bother modifying packages.x86_64 and building again? [https://www.memesmonkey.com/topic/works+on+my+machine <s>''on my machine''</s>] Darren "Un1Gfn" "[[User:PXf|PXf]]" Ng ([[User talk:PXf|talk]]) 08:18, 12 October 2021 (UTC)<br />
<br />
:It is a subsection of "Tips and tricks", not "Troubleshooting", so it should start with a clear motivation saying ''why'' the tip is useful, rather than an error message that the user has no idea if they will face or not. If you have such description, feel free to rewrite the section. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 05:42, 13 October 2021 (UTC)<br />
<br />
::What about making it a subsection of "[[Archiso#Troubleshooting|Troubleshooting]]" and renaming it to {{ic|partition / too full}}? [[User:PXf|PXf]] ([[User talk:PXf|talk]]) 06:45, 13 October 2021 (UTC)<br />
<br />
:::It's better to motivate it as a tip/trick rather than solve the problem after it happens. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:48, 13 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
(Undo revision 699881 by Oliver (talk) - installing arch-install-scripts does not get the image to "the same footing" as the archiso, even installing something for the first time is not an excuse to violate Help:Style#Package management instructions)<br />
<br />
'the same footing' may be poor choice of wording maybe but it's also not false. You are in a SIMILAR place, not 'exactly identical to the dot' e.g. same footing<br />
<br />
but 'installing something for the first time' is NOT what is going on here really. If we quote the style guide:<br />
<br />
''every Arch user should know pacman's article by memory''<br />
<br />
<br />
The thing is, this is NOT an Arch user yet. They have no idea what's going on, how to do stuff and just want to get started and installed. You can't expect _new_ not-yet-a user, to figure out everything in a daunting installation; by being a smart-bum about it. Yes, the style guide is completely correct on all other points. But I would think that this is the exception, rather then the rule. Help your new users a little. Introduce them gentle with open arms. From a 'first UX kind of way, this is horrible to treat your potentially new users.<br />
<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 17:40, 26 October 2021 (UTC)<br />
<br />
:We use the same convention on the [[Installation guide]] itself. They should read the [[pacman]] page to learn how to install packages as soon as possible, so why not right when they use it for the first time? There is a gentle link to "[[install]]" before the package name, so the clueless user will follow the link and learn something. They will not learn anything by copy-pasting a quick one-liner. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 26 October 2021 (UTC)<br />
<br />
Yes, you ARE right, however; this is the install guide (relatively speaking) Let them install the system first with a gentle nudge; THEN force them to learn stuff :p<br />
<br />
Again, I understand the policy and the reasoning behind it very much so; but it's those first few steps that are the hardest. It's birds vs humans I suppose; birds through their children out of their nests to teach them to fly (or die); Humans raise their children first. Is arch really the 'l337 fly or die, rtfm n00b' kind of distro?<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 18:25, 26 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
skip the rsync protocol<br />
<br />
As per my 'commit message' The user is confronted with the following:<br />
WARNING: failed to rate rsync download (rsync://mirror.erickochen.nl/archlinux/community/os/x86_64/community.db): [Errno 2] No such file or directory: 'rsync'<br />
<br />
You really think we should not reflect this in the documentation for now, until this dependency is actually properly resolved in the package? (could be weeks?)</div>Oliverhttps://wiki.archlinux.org/index.php?title=User_talk:Lahwaacz&diff=700018User talk:Lahwaacz2021-10-26T18:25:09Z<p>Oliver: /* Install Arch Linux via Docker */</p>
<hr />
<div>== bot checking links after move ==<br />
<br />
Hi, re [[Talk:Touchpad Synaptics#adding libinput alternative]]. [[Touchpad Synaptics]] has 100+ backlinks and the more important ones - a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of [[Touchpad Synaptics]] and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:36, 26 September 2015 (UTC)<br />
<br />
:Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a [[UUID]] page, which was later generalized and renamed to [[Persistent block device naming]] and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace <nowiki>[[pacman|Install]]</nowiki> with <nowiki>[[Install]]</nowiki> etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:01, 26 September 2015 (UTC)<br />
<br />
::Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [https://wiki.archlinux.org/index.php/Special:WhatLinksHere/Beginners'_Guide]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:02, 26 September 2015 (UTC)<br />
<br />
== mkosi ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=Systemd-nspawn&diff=0&oldid=491975 revert]: You can use mkosi also to create a container/directory tree (-t directory). So it can do the same and more. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 11:33, 1 October 2017 (UTC)<br />
<br />
:Alright, how is the "more" relevant to systemd-nspawn though? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:30, 3 October 2017 (UTC)<br />
<br />
::Hi, mkosi let's you create images (or directory trees) of various different distributions and allows you to do things like setting the root-password or installing additional packages. systemd-nspawn alows you to boot such images/directory trees. So I thought mentioning mkosi as alternative to manually creating a container with pacstrap or debootstrap would be worth it. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 22:23, 5 October 2017 (UTC)<br />
<br />
== Waking from suspend with USB device ==<br />
<br />
Hi Lahwaacz, thanks for your input on this topic.<br />
Can you help me a bit further, I know the USB host controller and the USB device are different things but I thought that enabling the host controller was not necessary anymore, see [https://www.spinics.net/lists/linux-usb/msg53661.html].<br />
In my case all the {{ic|driver/*/power/wakeup}} are all enabled by default and the {{ic|/proc/acpi/wakeup}} as well.<br />
Anyway I have added a step in my explanations to identify the path awaiting for more clarity.<br />
<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 21:57, 16 January 2018 (UTC)<br />
<br />
:Hi, thanks for the link, it's entirely possible that something changed since the section was written. However, in my case only the keyboard device has wakeup enabled by default: {{bc|<nowiki><br />
$ for f in /sys/bus/usb/drivers/usb/*/power/wakeup; do echo "$f: $(cat $f)"; done<br />
/sys/bus/usb/drivers/usb/1-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/2-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-11/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-12/power/wakeup: enabled<br />
/sys/bus/usb/drivers/usb/3-13/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-4/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb2/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb4/power/wakeup: disabled<br />
</nowiki>}}<br />
:But in practice it seems to wake up the system even without the host controllers enabled for wakeup... It might also depend on some BIOS/firmware settings but if it works by default on most systems then I think the host controller settings could be removed again.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:14, 19 January 2018 (UTC)<br />
<br />
== Are supported local/remote destinations important for choosing a backup program? ==<br />
<br />
You [[Special:Diff/525550|reverted]] my edit adding supported backup destinations to [[Synchronization_and_backup_programs]]. This is puzzling to me. Here are some thoughts:<br />
* if choosing any backup program, the ability to send the backup off-site vs only on a local disk is a key feature consideration. Perhaps *the* key feature: one helps me recover in case my house gets burglarized or burns down, and the other does not. This is a much more important feature consideration than, say, whether the program is written in Go or Mono (something that has a full column). I think it's hard to disagree on that.<br />
* Given this, I am very puzzled you would use the term "useless" in the revert message.<br />
* I assume you didn't like that the table got even bigger (it didn't fit into the layout even before). I don't like it either, but perhaps the revert should have said "can you put this somewhere else, not in this already-too-big table?"<br />
* On a personal note, when I provide feedback or give opinion on somebody else's work, I'd like to be constructive and kind, instead of aggressive and putting people down. Just a thought. Thanks for listening.<br />
<br />
[[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 17:38, 11 June 2018 (UTC)<br />
<br />
:No because you can use any remote back-end with any backup application by just running one command / writing the backups to a [[FUSE]] (if available).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:39, 12 June 2018 (UTC)<br />
<br />
::Hmm, by that reasoning we don't need the Arch package repository, as long as we have source code and makepkg. Or Perl, if we have bash and awk. But even then, and if all the fuse backends existed (I doubt they do), and if it were easy to set all of them up (another thing I doubt), do you indeed believe that running something written to read/write local files will be just as efficient backing up gigabytes of data to a remote repository as something that is specifically optimized for that use case? Note that backing up, say, daily, a typical hard drive via tpyical consumer broadband is still quite a bandwidth challenge in many places today. What about we add this info, and remove (or merge) some other columns to make the table smaller? {{Unsigned|18:08, 12 June 2018|Jernst}}<br />
<br />
:::Your comparisons don't make sense. Mind the slash in my response, you do not need a FUSE implementation, a simple CLI suffices. You do not need to "set all of them up", you only need one. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 18:47, 12 June 2018 (UTC)<br />
<br />
::::If you ever attempt to help a normal user set up a reliably-working off-site backup strategy, think of this discussion. In the meantime, this is all the time I'm going to spend on a discussion that has such repeated gems in it as "makes no sense" without explaining why you think so. Have a nice day. [[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 18:54, 12 June 2018 (UTC)<br />
<br />
== The pip section in [[Python package guidelines]] ==<br />
<br />
Hi, you wanted the warning about using pip or wheels restored but accidentally(?) reverted my whole set of changes. I redid them, leaving the warning in place. – [[User:Flying sheep|flying sheep]] 08:17, 8 March 2019 (UTC)<br />
<br />
:Full revert was intentional, because the "wheel" section is not a full replacement for "pip" because there are packages which don't provide wheel files. As I said in the edit summary, there is no reason to recommend one or the other due to the warning. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 8 March 2019 (UTC)<br />
::That still doesn’t explain why you reverted the first part, that had nothing to do with the pip/wheel section and simple improves the files.pythonhosted.org URLs. I restored that one while we’re discussing the pip/wheel section. And about that: There’s no reason to use pip for anything else, and pip is only used because some people (me included) didn’t understand that you can install most wheels by just extracting them to the correct location. So what do you think is missing from my wheels section that the former pip section had? – [[User:Flying_sheep|flying sheep]] 11:41, 11 March 2019 (UTC)<br />
<br />
:::If you didn't notice, the page includes "guidelines" in the title. So the page should contain only common and recommended ways to do things, not everything that is possible to do. If you think that your way to install "wheels" should be followed by everybody, feel free to discuss it on the talk page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:26, 11 March 2019 (UTC)<br />
::::Well, extracting static archives sounds much more recommended than running pip with like 7 options to make it behave. I added a talk item: [[Talk:Python package guidelines#Remove_pip_section_in_favor_of_wheels_section?]] – [[User:Flying_sheep|flying sheep]]<br />
<br />
== wpa_supplicant ==<br />
<br />
Regarding https://wiki.archlinux.org/index.php?title=WPA_supplicant&diff=577215&oldid=577167, one person ran into this problem in March of this year and spent too much time diagnosing it:<br />
<br />
https://bbs.archlinux.org/viewtopic.php?id=244950<br />
<br />
It took me a few days to find the problem. I want to make sure the next time someone encounters it, they easily find relevant information about what the cause is. Since you've reverted my edits to both netctl and wpa_supplicant, what do you suggest?<br />
<br />
--<br />
<br />
[[User:Pooryorick|Pooryorick]] ([[User talk:Pooryorick|talk]]) 08:24, 18 July 2019 (UTC)<br />
<br />
== F2FS and GRUB ==<br />
<br />
Hello. :) I'm here to address a recent disagreement. I noticed a reversion of my edit regarding the F2FS filesystem, in particular regarding the configuration file to edit (with you representing /boot/grub/grub.cfg and me representing /etc/default/grub). I run F2FS on my daily driver with an encrypted root filesystem and encrypted boot on a separate partition, and have never had to touch grub.cfg. I only automatically generate it. It's possible to use either, but /etc/default/grub would make more sense as a recommendation in my mind because grub.cfg has the potential to be overwritten during updates, whereas /etc/default/grub doesn't. <br />
<br />
If there's a compelling reason to use grub.cfg over /etc/default/grub, please let me know. ^^ I'm always eager to learn more about Arch. I don't want to get in a reversion war so I've left your change untouched for the time being.<br />
<br />
[[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 00:17, 8 September 2019 (UTC)<br />
<br />
:The reason is explained in the section: "If GRUB is used with an unsupported filesystem it is not able to extract the UUID of your drive so it uses classic non-persistent /dev/sdXx names instead." If it does not apply to F2FS, it should be made clear. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:29, 8 September 2019 (UTC)<br />
<br />
::You can specify UUID's in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, so my proposed solution would work for F2FS and other unsupported filesystems, without the burden of manually editing grub.cfg. If there's anything I need to clarify or something else I'm missing, just let me know. :) [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 19:37, 8 September 2019 (UTC)<br />
<br />
:::The {{ic|1=root=}} parameter is not supposed to be in GRUB_CMDLINE_LINUX_DEFAULT, regardless if UUID is used or not. ''grub-mkconfig'' automatically detects the root filesystem and adds the appropriate {{ic|1=root=}} parameter based on GRUB_DISABLE_LINUX_UUID. In any case, your change to the paragraph does not make sense. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:02, 8 September 2019 (UTC)<br />
<br />
::::It could simply be because I use full disk encryption, and adding a kernel parameter for the encrypted disk's UUID is correct in that situation. You're more experienced with contributing to the wiki, so I guess I'll defer to your judgment. It felt like a reasonable edit and solution to me and I don't see the downside to including it in GRUB_CMDLINE_LINUX_DEFAULT. [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 05:38, 9 September 2019 (UTC)<br />
<br />
== dracut executable link ==<br />
<br />
Hello, your last edit on the dracut page (https://wiki.archlinux.org/index.php?title=Dracut&oldid=596388) that undid my 'Link to direct "make executable" section for executable link' commit states: "the redirect executable points exactly to that section", but it doesn't. Following the [[executable]] link just points to the top of the Help:Reading page.<br />
<br />
{{unsigned|17:06, 28 January 2020|Krathalan}}<br />
<br />
:In that case your browser probably does not work correctly, because the redirect [https://wiki.archlinux.org/index.php?title=Executable&redirect=no really points to the section]. Or MediaWiki, there was a bug several years ago... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 28 January 2020 (UTC)<br />
<br />
:: How strange... thanks for pointing that out. It does indeed appear to be some issue with my Firefox configuration. [[User:Krathalan|Krathalan]] ([[User talk:Krathalan|talk]]) 19:51, 28 January 2020 (UTC)<br />
<br />
== Getting install.php work in DokuWiki ==<br />
<br />
Hi, than you for having undone my contribution and pointed to the right solution on [[Dokuwiki#Configuration]]. Indeed I had read this solution before, but I was misled by the condition "if you are using lighttpd or nginx and your PHP version is lower than 7": as I use Apache with php v. 7.4.3 I didn't take it into account. Do you know what a correct rephrasing could be? Maybe it should be deleted?<br />
<br />
Also, I think that, at the end of this same section, one should add something like "verify that {{Pkg|php-gd}} is installed and restart {{ic|php-fpm.service}}".<br />
<br />
Naturally I can do it myself, but I prefer to ask before.<br />
[[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 17:31, 19 February 2020 (UTC)<br />
<br />
:Hi, apparently it depends on whether you had {{ic|open_basedir}} set previously or not. I've changed the page, feel free to update the gd extension. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:16, 19 February 2020 (UTC)<br />
<br />
::Thank you! However, while, I didn't have {{ic|open_basedir}} set previously, I couldn't access ''install.php''. I suspect there is another thing to do, since the configuration editor in DokuWiki complains that it cannot modify the configuration files although ownership and permissions are correctly set for the relevant symlinks, directories and files, and so is {{ic|open_basedir}}. However I can edit my pages. Maybe a return from a new user with a fresh installation would be more useful, though. [[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 08:20, 20 February 2020 (UTC)<br />
<br />
== Dead link in Simple stateful firewall#See Also ==<br />
<br />
Hi, Jakub. I am about [https://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&diff=599725&oldid=599717 this] edit. I tried to follow that link one more time and it is not require entering captcha. I am not see any content limitations and my colleague (he uses Tor) does not see them too. I am not sure how it works, so I leave it on your descision. -- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 14:29, 1 March 2020 (UTC)<br />
<br />
:Well, maybe it depends on the location from which the request comes. But I don't know how it works either... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:33, 1 March 2020 (UTC)<br />
<br />
::my guess is it returns captcha for crawlers only -- [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 01:59, 2 March 2020 (UTC)<br />
<br />
:::I'm getting it in my browser... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 2 March 2020 (UTC)<br />
<br />
== SystemD user units depending on graphical session ==<br />
Hi,<br />
regarding reverting my addition to [[Systemd/User]], could you please explain why? I referenced [[https://www.freedesktop.org/software/systemd/man/systemd.special.html]] which directly contradicts what you said in your summary.<br />
<br />
{{unsigned|19:53, 5 May 2020|Fuero}}<br />
<br />
:The note in [[Systemd/User#How it works]] still applies - systemd services are never per-session, but per-user. The service does not magically get the correct DISPLAY or WAYLAND_DISPLAY variable, it does not work if you have multiple sessions per user, etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:45, 6 May 2020 (UTC)<br />
<br />
== Plymouth ==<br />
<br />
Actually with just Plymouth it does not work properly. Even 0dd17y had the same issue in https://bbs.archlinux.org/viewtopic.php?id=220900.<br />
<br />
The reason I did not file a bug report is that it is anyway fixed in the git version and the latest release (0.9.4) is around 2 years behind master<br />
<br />
{{unsigned|09:50, 6 May 2020|M.Srikanth}}<br />
<br />
:So if you don't have to file a bug report, add a full troubleshooting entry or at least properly reference your inline note instead of resorting to plain "if that does not work, try this instead". -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:15, 6 May 2020 (UTC)<br />
<br />
== [Bitcoin core] build the code and run the test suites ==<br />
<br />
Hello,<br />
<br />
This week, I managed to build the Bitcoin code and run all the test suites with the help of this page: https://jonatack.github.io/articles/how-to-compile-bitcoin-core-and-run-the-tests<br />
<br />
Archlinux has two particularities:<br />
* being in rolling release, it takes to manually use the library {{ic|Berkeley DB (BDB) v4.8}}<br />
* the {{ic|/tmp}} directory is by default limited to half the size of the Ram<br />
<br />
For these reason, maybe it could be interesting to have a page in the wiki to explain how to build the Bitcoin core?<br />
<br />
Cheers,<br />
<br />
Thomas<br />
<br />
[[User:Thomasb|Thomasb]] ([[User talk:Thomasb|talk]]) 20:29, 9 May 2020 (UTC)<br />
<br />
:I don't think that this is useful. There is the {{AUR|bitcoin-core-git}} package and nothing more should be needed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:53, 26 May 2020 (UTC)<br />
<br />
== Double linefeed results in extra line ==<br />
<br />
If you look at templates that end with double linefeed before noinclude this would result in extra line in resulting page.<br />
<br />
It may be a minor point but since you are perfectionist about wikitext I should mention this is a tradeoff and it results in slightly worse result.<br />
<br />
Removing just one linefeed removes the problem while still allowing it to not jumble all the tags into same line.<br />
<br />
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:30, 11 May 2020 (UTC)<br />
<br />
:If this is about [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=next&oldid=612179], the spaces I added back are not included when the template is used elsewhere, because the spaces are inside the noinclude tags. The extra space is only on the template page itself, but it does not result from template inclusion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:41, 11 May 2020 (UTC)<br />
<br />
::OFC, I mean the template page render has extra line. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 21:21, 11 May 2020 (UTC)<br />
<br />
:::I agree with [[User:Svito|Svito]], isn't it good to delete the extra blank lines? -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 05:39, 12 May 2020 (UTC)<br />
<br />
::::OK, let's do it. [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=616382&oldid=612181] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:47, 26 May 2020 (UTC)<br />
<br />
== Re: lighttpd: remove python2 version ==<br />
<br />
Instead of removing the example we could as well add an example using a Python3 library like https://pypi.org/project/flup6/.<br />
<br />
{{unsigned|15:23, 18 May 2020|Gruentee}}<br />
<br />
:Feel free to add it if you find it useful. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:56, 18 May 2020 (UTC)<br />
<br />
== Xbindkeys removal ==<br />
<br />
Hi, just wondering why you [https://wiki.archlinux.org/index.php?title=Xbindkeys&diff=617675&oldid=617670 removed my edit] from [[Xbindkeys]]? The xbindkeys page has a number of quick tips but no mention of how to bind anything to the Print Screen key so I thought it would be useful to add. -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 02:27, 3 June 2020 (UTC)<br />
<br />
:Giving examples for all keys on the keyboard is useless, there is [[Xbindkeys#Identifying keycodes]] which teaches how to find the keycodes and keysyms of any key. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 3 June 2020 (UTC)<br />
<br />
:: So how come you left the examples for the volume up/down and brightness? What is different between those examples and a screenshot example? Aren't more examples better to save people from hunting all over the place trying to piece things together themselves? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 14:03, 4 June 2020 (UTC)<br />
<br />
:::The difference is that when it comes to volume control, there are 1 or 2 options for the 99% most common cases, but for screenshot taking there are dozens of different options. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:15, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for edit to XDG Base Directory page regarding python_history ==<br />
<br />
I understand the justification for reverting the change I made, however I would like to point out that similar entries on the page (such as Maven) also have instructions for what contents to put in files (even though there is native documentation for those settings). Additionally, it took me a bit of re-reading on the linked Python documentation to reason out how the documentation's example needed to be modified, since it's not clear from the Python documentation whether placing such code in the PYTHONSTARTUP file will actually ''override'' the default behavior. [[User:Varriount|Varriount]] ([[User talk:Varriount|talk]]) 20:44, 20 June 2020 (UTC)<br />
<br />
:Even maven's note can be [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=631704&oldid=631630 shortened]. The notes in the table must be as short as possible, there is no place for extended explanations or long code snippets like in the upstream documentation. If the Python's documentation is not clear enough, I don't think any note in a massive convoluted table will ever be better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:47, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for Backlight page ==<br />
<br />
Hi, you reverted my change to [[Backlight]] page that mentioned WIP patches for controlling OLED panel brightness. I don't really understand justification for reverting it since currently the page says that OLED brightness can be controlled only by changing gamma ramp. That is wrong - since it's not the only way - these panels can control brightness with a PWM. Moreover controlling brightness with gamma ramp is not optimal - it essentially reduces dynamic range, i.e. at 50% you have 7 bits per pixel, at 25% - 6 bit per pixel, etc. That results in banding artifacts at lower brightness level.<br />
<br />
As far waiting for the patches to be merged before mentioning it there - it'll take ~3-6 months (yes, that's the process) and I haven't found *any* reference to these changes on the internet - everyone recommends using gamma ramp instead of fixing it properly. I'm absolutely sure that having information about these patches would not hurt [[User:Anarsoul|Anarsoul]] ([[User talk:Anarsoul|talk]]) 15:56, 30 June 2020 (UTC)<br />
<br />
:Linking to a repo which which has 2 custom commits on top of some arbitrary development version of the Linux kernel tree is not helpful for users. Nobody will compile directly from this repo which is already significantly outdated compared to recent kernel versions and there is no indication if the patches actually work with newer (or older) kernels. We can mention the PWM control as a general concept though. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:32, 12 August 2020 (UTC)<br />
<br />
== Automatic template correction ==<br />
<br />
Per [[Help:Template#Style]], templates should be used with the capitalization shown in the examples in their pages, so {{ic|&#123;{AUR&#124;...}} is correct, while {{ic|&#123;{aur&#124;...}} is not.<br />
<br />
However, there are pages that don't respect that rule (e.g. [[Android_Debug_Bridge]] until recently).<br />
<br />
I beleive this correction should be easy to implement using a bot. What do you think?<br />
<br />
{{unsigned|07:24, 25 August 2020|Relrel}}<br />
<br />
:Yes, this should be easy, but the bot should not make a huge amount of simple style-only changes - they should be combined with corrections for more complex rules. Anyway, there is an idea to create a [https://github.com/lahwaacz/wiki-scripts/issues/22 style linter] for the ArchWiki rules. Would you like to help? ;-) – [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:21, 25 August 2020 (UTC)<br />
<br />
== Failed to create tun device ==<br />
<br />
I don't understand your reason for [[https://wiki.archlinux.org/index.php?title=NetworkManager&diff=0&oldid=634880 removing my section in NetworkManager]]. Could you elaborate?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 07:40, 11 September 2020 (UTC)<br />
<br />
:You can't use [[systemd-networkd]] and [[NetworkManager]] at the same time. Even if you don't have any ''.network'' file for systemd-networkd, you can't solve NetworkManager's problems with systemd-networkd. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:43, 11 September 2020 (UTC)<br />
<br />
::Ok, thanks, in this case it solved the error I got. Now the VPN works. Do you have an idea about how to solve it without systemd-networkd?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 22:27, 11 September 2020 (UTC)<br />
<br />
:::You should really fix the permission problem for {{Pkg|networkmanager-openvpn}}. The tun interface should be managed by OpenVPN which needs rights to create it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 12 September 2020 (UTC)<br />
<br />
::I don't think this statement is entirely correct. [[systemd-networkd]] and [[NetworkManager]] can happily co-exist together if they are managing different interfaces. I unfortunately don't have a reference to point to this, but I came across this being mentioned a couple of times on forums. I personally use [[NetworkManager]] on my laptop to handle wifi, while [[systemd-networkd]] is in control of virtual ethernet and bridges for all my [[systemd-nspawn]] instances. [[User:Romstor|Romstor]] ([[User talk:Romstor|talk]]) 03:24, 12 September 2020 (UTC)<br />
<br />
== [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&oldid=636526/ XDG Base Directory]: Undo revision 636525 ==<br />
<br />
Dear Lahwaacz,<br />
<br />
maybe my changes were to rushed and from my point of view only. But I have two points to consider:<br />
<br />
# If I put the quotes around my vimrc and source it from my .bash_profile, I get the vim-error E471 (Argument required). Without quotes, this doesn't happen. So this change based on experience.<br />
# The rtp should includes directories, which are needed at runtime. (in plain vim e.g. ~/.vim). This is not a typical configuration directory. My mistake was, that I supposed that everyone put their vim plug-ins in $XDG_DATA_HOME and not in $XDG_CONFIG_HOME, because from my point of view a plug-in doesn't belong to the configuration. Maybe it is a good idea to add a remark, which explains the addition of $XDG_CONFIG_HOME to the rtp.<br />
<br />
[[User:Grrr|Grrr]] ([[User talk:Grrr|talk]]) 13:53, 26 September 2020 (UTC)<br />
<br />
# Quotes are there because $XDG_CONFIG_HOME may contain spaces.<br />
# It's not only about quotes - the runtimepath has subdirectories for color schemes, keymaps, autoload scripts etc.<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 26 September 2020 (UTC)<br />
<br />
== Readability in Wiki ==<br />
<br />
I noticed that you and the other admins and moderators often want sentences to continue endlessly, without line breaks.<br />
For example in the introduction of [[Wayland]].<br />
<br />
I think it would be better to have more seperated sentences, so it is easier to read and "important" information is easier visible for people.<br />
I don't know who is responsible, but maybe some options in MediaWiki (or whatever this wiki software is) could be changed as well, to make make line breaks etc. easier and reduce the height-space (if you know what I mean) between sentences, so it looks better, even though line breaks are used.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:38, 15 October 2020 (UTC) G3ro<br />
<br />
:I don't know exactly what you mean. Is it about the readability of the rendered HTML or the "source code" of the page? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:15, 15 October 2020 (UTC)<br />
<br />
:: Well I guess it can be about both. But mainly it is about what people see on the page.<br />
:: There are three seperate topics I mentioned:<br />
<br />
:: 1. Use line breaks: I would like to use more line breaks, because if you have long sentences that are written after each other without line breaks, it gets "harder" to recognize when the next sentence starts.<br />
:: While I agree to what you said somewhere, that sentences that belong directly together, should be written in one "paragraph", it would be useful for sentences that cover (slightly) different "topics" to be visibly parted.<br />
<br />
:: 2. Adjust margin options: I notice that when line breaks are used, there is a vertical space added between two sentences. Just like in this post. If you would use line breaks more often, this is a little too much spacing in my oppinion.<br />
<br />
:: 3. Potential options to make line breaks easier: It would be very convenient if a line break in the source code would lead to a line break in displayed text as well, instead of needing to add an empty line.<br />
<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:33, 15 October 2020 (UTC) G3ro<br />
<br />
:::OK, now I understand. I agree that splitting different topics usually improves legibility, but they should be split into separate paragraphs and not just by line breaks (e.g. using the &lt;br> tags). Paragraphs are semantic units whereas line breaks inside a paragraph are usually typographic errors.<br />
:::Also note that such splitting alone may not be enough to improve the text flow. For example, if we consider the intro for [[Wayland]], the second sentence about XWayland would not constitute a good paragraph - it is just a plain statement and the new topic is not nicely introduced. Ideally, you'd split the topic and make some wording changes for the second paragraph.<br />
:::As for the margin options, that is the difference between paragraph splitting and non-semantic line breaks. In my opinion, the styling is correct in this respect, as paragraphs should be discernible. You mentioned that you like line breaks to easily recognize where a sentence ends - but reading should be based on whole paragraphs, not sentences. There should be no reason to skip anything in the middle of a paragraph, otherwise it should be probably split into multiple paragraphs or otherwise rephrased.<br />
:::If you find it hard to follow a long sentence horizontally on a wide screen, we might consider enforcing some maximum width for the whole content. I think the readability would be better, since there would be more top-to-bottom eye movement at the cost of left-to-right-and-back.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:59, 15 October 2020 (UTC)<br />
<br />
== Xorg parentheses ==<br />
<br />
I actually think that X(org) is very useful to imply that it is one and the same thing.<br />
<br />
It might even be more confusing now, as we use both Xorg and X, because the wiki title and the package titles are Xorg.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:30, 17 October 2020 (UTC) G3ro<br />
<br />
:Well the conventions should be established on the [[Xorg]] page, not anywhere else... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:36, 17 October 2020 (UTC)<br />
<br />
:: Imo the conventions are established by upstream and they use a wide variety of X, X.org, X(org), Xorg etc.<br />
:: As I said I always prefer X(org) because then it is clear, that both are same thing.<br />
:: But ultimately it's your decision. <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:43, 17 October 2020 (UTC) G3ro<br />
<br />
:::When upstream is not capable of making a unambiguous decision, it makes sense that other projects pick some option and stick with it wherever they can to keep at least some consistency. So for this wiki, pages should use the same style as the [[Xorg]] page. But feel free to start a discussion about this in [[Talk:Xorg]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:56, 17 October 2020 (UTC)<br />
<br />
== SSHFS - systemd edit ==<br />
<br />
The edit was removed because "there is no advantage over using fstab entries".<br />
<br />
Is not only about the dis/advantages of the systemd option, is about that it is another possibility to achieve the task, that is why it was created in another level and the fstab section was left alone.<br />
<br />
Reconsider the edit as it presents another option which people can use.<br />
<br />
[[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 16:22, 22 October 2020 (UTC)<br />
<br />
:There is no need to use anything else, fstab just works well enough. Configuring mounts with systemd services is not a good idea - it is much more bloated than fstab and not the right tool for it. If anything, a different type of systemd units should be used: {{man|5|systemd.mount}}. But creating the mount units manually is still pretty useless since everything can be configured in fstab and systemd will generate the unit for you. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:22, 22 October 2020 (UTC)<br />
<br />
:: It is about the ability to use the user's .config file and all the proper options that are saved there. Also systemd gives the possibility to use different targets, so the user could mount it when an specific user logs in or when a graphical session starts. I could argue that bad a modification of fstab could lead to a system that doesnt boot, but such poorly configured systemd unit file just fails and the system is fine. Just give the user the information and let it decide what they can use depending on their use case. [[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 08:08, 24 October 2020 (UTC)<br />
<br />
:::You can configure systemd targets in fstab using the {{ic|x-systemd.wanted-by}} and {{ic|x-systemd.required-by}} options, there are also {{ic|nofail}} and {{ic|noauto}} options. Please read the {{man|5|systemd.mount}} manual.<br />
:::Using hosts from the user's {{ic|.ssh/config}} is the only thing which is not possible with fstab, but this does not warrant using the wrong tool for the task. Simple copy the full {{ic|user@hostname}} into fstab and you're done.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:47, 24 October 2020 (UTC)<br />
<br />
== [[Self-encrypting drives]] ==<br />
<br />
Hi, I'd like to respectfully disagree with the rollback. It's specific to sedutil that with most commands you need to input /dev/nvme0 (when encrypting the device) but for the sleep commands it requires /dev/nvme0n1 or it fails with a very unspecific error (Error saving the password to the kernel errno = 25), as found out in the discussion https://github.com/Drive-Trust-Alliance/sedutil/issues/90<br />
<br />
All in all I believe that it is important to keep this piece of information which was found out in a long discussion between the reporter and the developers. I ran into it and I believe many people may run into it, considering most of the new SSD will be NVMe. Best, [[User:Przemub|Przemub]] ([[User talk:Przemub|talk]]) 13:34, 28 October 2020 (UTC)<br />
<br />
:OK, then it makes sense. But it should be probably explained before, not in the section about the sleep command. Also please add the link to the note as a reference. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:27, 28 October 2020 (UTC)<br />
<br />
== Nvidia Installation ==<br />
<br />
The whole guide is unnecessary long and overcomplicated formulated.<br />
Shorter is better, most people will know their graphic card for example, so the determination etc. is only optional.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:21, 10 November 2020 (UTC) G3ro<br />
<br />
:Moving some info to some other page and leaving a tip behind does not make it shorter, but harder to follow. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:36, 10 November 2020 (UTC)<br />
<br />
== Btrfs layout ==<br />
<br />
Hi, Lahwaacz<br />
<br />
Thanks for maintaining [[Snapper]]! However I think the layout is not openSUSE specific and beneficial to all btrfs users. Can you elaborate your reason of undoing the edits? IMO the previous 'simple layout' complicates the rollback procedure.<br />
<br />
Cheers,<br />
[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 07:26, 3 December 2020 (UTC)<br />
<br />
:It is not overcomplicated, it is just doing things right. You can read about that in the forum thread, see the first note in [[Snapper#Suggested filesystem layout]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:24, 3 December 2020 (UTC)<br />
<br />
::Anyway I've moved the guides to my user page. It's not that I haven't read the 5-year-old forum post, it's that before the current layout I followed that post and resulted in a not fully rolled-back system. That post also sourced (then current) information from openSUSE. openSUSE has since massively overhauled the layout, as I pointed out in an edit you undid earlier.[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 09:02, 3 December 2020 (UTC)<br />
<br />
::Since last message I've extensively documented the new layout at [[User:I2Oc9/Btrfs_subvolumes]] and [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption]]. Have a look for yourself. Nothing new really, but IMO [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my take]] is much more simpler and complete than the supposedly [[Snapper#Restoring_/_to_a_previous_snapshot_of_@|simpler one]]. That one does not leverage native {{ic|snapper rollback}} or {{Pkg|grub-btrfs}}, among other things. I strongly suggest you try if you have time. [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 11:55, 3 December 2020 (UTC)<br />
<br />
::Actually if you look closely, none of [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my recovery methods]] is specific to [[User:I2Oc9/Btrfs_subvolumes#A_new_kind_of_layout|the new 'complex' layout]], it will work totally fine with the old one. I just don't think moving @ around in live environment is appropriate.<br />
<br />
::On the other hand, the layout recommendation has been updated by openSUSE [https://en.opensuse.org/SDB:BTRFS], why stick with the old one? [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 12:37, 3 December 2020 (UTC)<br />
<br />
:::The main reasons why I reverted your edits on the [[Snapper]] page are: 1) it was a huge change which was not discussed previously as required by [[ArchWiki:Contributing#The 3 fundamental rules]], and 2) it has some elements which do not apply to Arch (see below). If you wish to propose a better layout of the subvolumes, it should be discussed in [[Talk:Snapper]] first. Your user pages would serve as great drafts.<br />
:::Note that the current suggested layout is not ''flat'' in the sense of [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|your section]] - it has a separate subvolume for {{ic|.snapshots}} so it does not lead to the recursive mess. So your proposed layout seemed very similar to the current suggested layout. The real difference is which subvolume gets mounted at {{ic|/}}, but I did not find it explained anywhere on the Snapper page before I reverted the changes (I get it now from your user page). I also did not find a proper documentation of the openSUSE's layout - it seems to be just the product of their installer and the documentation only deals with the result, saying at most that [https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-snapper.html#sec-snapper-snapshot-boot the subvolume configuration must not be changed] for rollbacks to work.<br />
:::Now the openSUSE-specific elements: some Arch packages actually install software into {{ic|/opt}}, so the recommended layout should not suggest a separate subvolume for this path. Even more importantly, the pacman database is located at {{ic|/var/lib/pacman/local/}} and it must be rolled back along with the system, so there should be no separate subvolume for {{ic|/var}}. Instead, users should be encouraged to create (even nested) subvolumes for specific data directories under {{ic|/var}}, such as {{ic|/var/log}}, {{ic|/var/tmp}}, {{ic|/var/cache/pacman}}, {{ic|/var/lib/machines}}, etc.<br />
:::Finally, the suggested layout should not be GRUB-specific, there should be no recommendations regarding a boot loader. Sure it is useful to include non-trivial tips, but people may actually use a different boot loader.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:31, 4 December 2020 (UTC)<br />
<br />
::::Thanks for your detailed reply. I admit that I'm not knowledgeable on the intricate differences between distributions and shouldn't have made the changes without properly discussing them first.<br />
::::Yes, I get that the current layout is not [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|the one described in this section]] and indeed properly separates {{ic|/.snapshot}} and {{ic|/}}. The layout I proposed attempts to add some "niceties" such as supporting multi-distribution installations (complex and unnecessary, I agree) and bring the openSUSE layout here, which is a mistake, as you've pointed out.<br />
::::As for GRUB, since I use LUKS all the time and it's the only bootloader supporting encrypted {{ic|/boot}} on Btrfs on LUKS1, I really didn't think of any other possibilities.<br />
::::I will incorporate your recommendations to my user page and add a new section in [[Talk:Snapper]] pointing to those pages.<br />
::::Cheers -- [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:09, 4 December 2020 (UTC)<br />
<br />
:::::I've adopted [[Install_Arch_Linux_on_ZFS#System_datasets|Archlinux Root on ZFS layout]] to [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Create_subvolumes|my proposal]]. [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:56, 4 December 2020 (UTC)<br />
<br />
== Reflector Revert ==<br />
<br />
Hi Lahwaacz, about your [https://wiki.archlinux.org/index.php?title=Reflector&oldid=643749 revert], it seems like there's precedence for including AUR packages that replicate the code on the wiki. For example, in [[dash#Relinking /bin/sh]].<br />
<br />
In addition, I believe that there's value for linking the AUR package because it allows a simpler user experience where the AUR package is maintained for them. That way, if it is ever updated, they can easily fetch the update instead of religiously checking the wiki page (which most users probably don't do).<br />
<br />
Thanks!<br />
<br />
[[User:Denton-l|Denton-l]] ([[User talk:Denton-l|talk]]) 01:52, 7 December 2020 (UTC)<br />
<br />
:That precedence was only created by [https://wiki.archlinux.org/index.php?title=Dash&type=revision&diff=561587&oldid=518398 yourself]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 5 May 2021 (UTC)<br />
<br />
== firefox zoom ==<br />
<br />
"no reason to zoom manually, see HiDPI)" - fractional scaling doesn't work [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 26 December 2020 (UTC)<br />
<br />
:That should be explained in [[HiDPI#Firefox]] anyway. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:48, 26 December 2020 (UTC)<br />
<br />
::it's good to have this mentioned somewhere clearly so people know about it before they say "fonts on linux suck" [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 15:51, 29 December 2020 (UTC)<br />
<br />
== Intel GVT-g edits ==<br />
<br />
Hello Lahwaacz,<br />
<br />
I have noticed that you reverted one of the edits I have performed on [[Intel_GVT-g]].<br />
<br />
About this revert: [https://wiki.archlinux.org/index.php?title=Intel_GVT-g&oldid=648062 Windows problems are out of scope]<br />
<br />
While I understand that the ArchWiki is about ArchLinux, this article in particular mentions Windows in the introduction, and already includes another troubleshooting point about Windows. The issue I have encountered with the black bars is somewhat common, as I have found other people discussing it online, and I really fail to see why not including this piece of information in this article would be better than including it.<br />
<br />
Please, let me know your thoughts. If you think that the point can be improved, I will be happy to do that.<br />
<br />
Ciao,<br />
<br />
[[User:Wilcomir|Wilcomir]] ([[User talk:Wilcomir|talk]]) 09:14, 3 January 2021 (UTC)<br />
<br />
:Well, the existing section about a Windows problem is actually solved by configuring the Linux host. I think anything involving configuration or installation of programs in Windows is not appropriate for long troubleshooting sections. At most, they could be mentioned in a short reference to other sites which describe the problem in detail. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:34, 3 January 2021 (UTC)<br />
<br />
== <s>XDG configuration for Vim</s> ==<br />
<br />
Hi Lahwaacz,<br />
<br />
You have reverted the updated Notes for Vim on [[XDG Base Directory]], because "copy-pasted from a blog post".<br />
<br />
The problem is, not only is the configuration presented currently also copied from a blog post too, but is already 10 years old.<br />
<br />
Would it be OK, if we bring back the more up to date version? Or at least remove the obsolete one and leave link to newer?<br><br />
(Although I think a copy on wiki would be beneficial in case my blog ceases to exist)<br />
<br />
[[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 02:05, 12 January 2021 (UTC)<br />
<br />
:OK let's close this. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:49, 29 August 2021 (UTC)<br />
<br />
== Root on ZFS draft ==<br />
<br />
Hi, I submitted [https://github.com/openzfs/openzfs-docs/pull/104 a Root on ZFS draft] to official doc repo.<br />
<br />
In the draft, the following directories are separated from root filesystem:<br />
home,root,srv,usr/local,var/log,var/spool,var/tmp<br />
<br />
Is this appropriate for Arch Linux? Or do you have any suggestion on the draft?<br />
Any comment is appreciated.<br />
[[User:M0p|M0p]] ([[User talk:M0p|talk]]) 01:28, 23 January 2021 (UTC)<br />
<br />
== Re: undo GRUB - Common installation errors ==<br />
<br />
Concerning your undo of [https://wiki.archlinux.org/index.php?title=GRUB&diff=next&oldid=649799 Add the error message `Could not prepare Boot variable: No space left on device`)]<br />
Is there a better place to for this Information? One can find the solution in various forums, but I thought it could be helpful to have it in this wiki somewhere. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 12:51, 25 January 2021 (UTC)<br />
<br />
:The error message is not specific to the {{ic|/sys/fs/pstore/}} filesystem (which does not even seem to be used by default on Arch...) Where did you find that? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:16, 25 January 2021 (UTC)<br />
<br />
::I did not find anything Arch specific, but this post about Debian helped: [https://donjajo.com/fix-grub-efibootmgr-not-set-variable-no-space-left-device/ Post]. I also found something about [https://askubuntu.com/questions/1072618/could-not-prepare-boot-variable-no-space-left-on-device-grub-install-error-ef /sys/fs/efi/efivars/dump-*] The problem is that the actual efi-partition does not seam to be the problem, there is more than 70% space left. If there is better information to guide the user in the right direction that wuld be more helpful. This is what I found worked, but I admit that I don't know much about how grub operates. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 16:20, 25 January 2021 (UTC)<br />
<br />
:::This wiki ''is'' Arch specific so old posts about Debian or Ubuntu do not apply. Even if they did, this is hardly a ''common'' installation problem. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:29, 26 January 2021 (UTC)<br />
<br />
::::I know that, and would not have put it there if it didn't occur on my Arch Linux installation. If this is something that should not be documented in this wiki, I understand that. Is there any other place you would recommend? An issue for grub-install maybe? [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 22:24, 26 January 2021 (UTC)<br />
<br />
== Kernel Compilation time ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Kernel&diff=next&oldid=650896 link]<br />
<br />
I don't think we should judge information by what is obvious to experts.<br />
People might have experience with compilation of other programs, which mostly is fast, and then there is the kernel which takes forever to compile.<br />
I think it does not hurt anyone to make people aware of it.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:03, 6 February 2021 (UTC)<br />
<br />
:It is an unnecessary information without a definite answer which can even be [https://html.duckduckgo.com/html?q=how%20long%20does%20it%20take%20to%20compile%20Linux%20kernel searched elsewhere]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:23, 6 February 2021 (UTC)<br />
<br />
:: I disagree, with that argument nearly any tip and note is unnecessary. These things are intended to inform users about things that should be taken into consideration and that are different from the norm.<br />
:: Also do you search for the compilation time for every program you intend to compile? I don't.<br />
:: Furthermore this info is included, why not tell it to people directly on the start, so they don't read over it? <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:36, 6 February 2021 (UTC)<br />
<br />
:::If someone wants to compile the Linux kernel, they should obviously expect that it will take ''some time''. Stating that it "can take up to several hours" does not make sense without referring to a specific hardware. Obviously, it will take much longer on a poor laptop than on a powerful workstation with a many-core processor, but people can assume that themselves. Without a reference to a specific hardware, the note is unnecessarily discouraging because the compilation can be as fast as some tens of minutes - it is by far not the most expensive package to compile...<br />
:::As you said, people can find better notes later along with advices to enable parallel build etc. which is all that's needed IMO.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:03, 6 February 2021 (UTC)<br />
<br />
== Wayland style ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Wayland&diff=prev&oldid=650979 link]<br />
<br />
I think in the old version it was much easier to read the "source code", so I don't see why there can't be spaces between it.<br />
Things shouldn't be complicated more than necessary.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:11, 6 February 2021 (UTC)<br />
<br />
:Most templates on the wiki are written without spaces around the |. When we [https://github.com/archlinux/archwiki/pull/32 switch the editor], there will even be syntax highlighting. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:25, 6 February 2021 (UTC)<br />
<br />
== Bluetooth keyboard ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php/Bluetooth_keyboard link]<br />
<br />
On your last change you said "not specific to keyboards, all of this is already mentioned on the Bluetooth page", the point is that this is extremely relevant for bluetooth keyboard since it is required to perform the login! If this little piece cannot be duplicated I would suggest at least to leave a link saying "If you want to autoconnect at boot please refer to...". I'm new here and I would not touch it further, but please evaluate the suggestion (this is because after reading bluetooth keyboard page and not finding the solution I had to look for it on forums)<br />
<br />
{{unsigned|21:17, 20 February 2021|Stevexyz}}<br />
<br />
:Well, basically the whole page is flagged to be merged with the main [[Bluetooth]] page, so it's expected to be incomplete. Other tips may always be found on a more general page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:40, 21 February 2021 (UTC)<br />
<br />
== Re: Steam Needs to be online error ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Steam/Troubleshooting&diff=next&oldid=653073 link]<br />
<br />
The problem here is that DNS resolution in general works already (yes even outside browsers), i.e. <br />
<br />
dig media.steampowered.com<br />
<br />
would run successfully, but the Steam client couldn’t resolve it. The DNS request from 'dig' shows up in my nameserver’s log, the one Steam should send doesn’t. This indicates it might indeed a problem specific to Steam, and it’s not as easy as just say "go fix your DNS resolution", as it already may work correctly for everything but Steam.<br />
<br />
Additionally, at no point does [[Domain name resolution]] even mention nscd, so you effectively removed a fix/workaround for the problem from the Wiki. So I was definitely not "duplicating an article" here. [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 08:12, 22 February 2021 (UTC)<br />
<br />
:Could I please hear your opinion on this? I’d be happy to just add something along the lines of "if you made sure DNS resolution works but Steam still can’t resolve it, try additionally enabling the nscd service" to the Steam troubleshooting page. Unfortounately I don’t know why running the service helps, but I’d still like to give others an easier time finding this solution than I had myself. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 09:15, 28 February 2021 (UTC)<br />
<br />
::Hi, I'm sorry for the delay. Could you test if using a different program for DNS caching (e.g. [[systemd-resolved]]) instead of {{ic|nscd.service}} fixes the problem? If not, then it's probably not due to DNS - {{man|8|nscd}} actually caches more than just DNS. Also if you have a reference to some website where you found about nscd, it would be nice to add it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 28 February 2021 (UTC)<br />
<br />
:::No worries. Using [[systemd-resolved]] for DNS resolution (and caching I guess, I wasn’t aware it does that, too) was a thing I did try, but that didn’t fix it for me. The place I found out about nscd fixing it was actually the [https://bbs.archlinux.org/viewtopic.php?id=263356 Arch forums]. When I search the web for Steam in combination with nscd, all I can seem to find are more forum entries of people that don’t know why that fixes it either. I can try a bit to find out what nscd does to make it work, but I’m not too confident I will be successful. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 14:51, 28 February 2021 (UTC)<br />
<br />
::::Okay, so {{ic|nscd}} allows to [https://man7.org/linux/man-pages/man5/nscd.conf.5.html dis-/enable caching per service], and it’s indeed enabling it for {{ic|hosts}} that makes it work. That’s weird though, since [[systemd-resolved]] has caching enabled by default, and using it for resolution didn’t make {{ic|steam}} work for me. Leads me to think that I didn’t set it up correctly, although resolving via {{ic|dig}} *did* work. Since [[steam]] depends on [[Name Service Switch]], I tried resolving using {{ic|getent}} manually with nscd disabled, but that worked while steam did not. I’m not really sure what to make of this, since I have no idea how this low level networking/resolving stuff works really. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 15:39, 28 February 2021 (UTC)<br />
<br />
:::::Hmm, I don't know the details either. Steam needs the multilib packages so maybe that's part of the problem. Could you add your findings to the section and use [[Template:Expansion]] for the missing details? Maybe someone can figure it out. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:44, 28 February 2021 (UTC)<br />
<br />
::::::Sure, I can do that. I’ll probably need a minute to figure out how to use the template though, but I should have the time later today. Thanks for your input on this. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 17:56, 28 February 2021 (UTC)<br />
<br />
== Removal of website link ==<br />
<br />
Refers to this: https://wiki.archlinux.org/index.php?title=PipeWire&diff=next&oldid=653701<br />
<br />
I don't understand why that has to be removed. The official website should be always worth a mention, even if it is somehow mentioned in the text already.<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:02, 28 February 2021 (UTC)<br />
<br />
:The "See also" section is for additional links, it is not intended as a collection of all links used on a page. Adding links which are clearly mentioned in the appropriate place only clutters the list. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:24, 28 February 2021 (UTC)<br />
<br />
:: There are just three links and only one of them is really useful, the others could maybe even be removed as they link to old blog posts.<br />
:: I can only repeat myself, that things don't always have to be made more complicated than necessary.<br />
:: The official website is a central point which links to many more useful ressources, so it's one link for much information.<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:34, 28 February 2021 (UTC)<br />
<br />
== Removal of bootia32.efi generation procedure from X205TA install page. ==<br />
<br />
Those [https://wiki.archlinux.org/index.php?title=ASUS_x205ta&diff=596239&oldid=562734 instructions] were really straightforward and useful, imho in comparison present ones require too much material to be confident with. I think it's (paradoxically) way easier to generate the file than to configure a `grub.cfg` from zero to boot a live cd. Can we undo the edit? Otherwise we could put them in a new page or section in the GRUB page and link to them maybe. [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 05:07, 4 March 2021 (UTC)<br />
<br />
:If there is something wrong with the information on the [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Booting_64-bit_kernel_on_32-bit_UEFI general page], it should be improved instead of describing the same procedure in a different way on a completely unrelated page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:16, 6 March 2021 (UTC)<br />
<br />
:: I didn't know we had that info in the UEFI article. I think it could be appropriate to insert the [https://en.wikipedia.org/wiki/Template:See_also#Examples See also] archwiki equivalent (which I couldn't find) for UEFI page on top of the aforementioned section, what do you think? [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 13:28, 7 March 2021 (UTC)<br />
<br />
:::Well, the removed section was previously flagged with "Duplicates [[Unified Extensible Firmware Interface#Booting 64-bit kernel on 32-bit UEFI]]"...<br />
:::Also the laptops pages are usually related to most of the general pages on this wiki, adding all of them would be pretty useless. Users should not expect to find everything on a single laptop page, they should always check if there is a general page for their topic with more details.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:58, 7 March 2021 (UTC)<br />
<br />
== Re: Show how to use systemd/Timers with wg-quick@.service ==<br />
<br />
I don't think using service is the appropriate when you want to start Wireguard at boot. For most people connecting to a VPN is not exactly part system startup.<br />
A timer should more appropriate.<br />
[[User:ENV25|ENV25]] ([[User talk:ENV25|talk]]) 10:03, 11 April 2021 (UTC)<br />
<br />
:I don't see how OnBootSec=1min is more appropriate than an automatically starting service. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:19, 11 April 2021 (UTC)<br />
<br />
== USB flash installation medium (BIOS bootable) ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=next&oldid=673926 revert]: "making the partition bootable is discussed below"<br />
Do you mean installing syslinux and `dd` the [gpt]mbr with "discussed below"? This was not enought for my setup (Sandisk Ultra 64GB, Dell XPS 9370) to make the partition BIOS bootable. It did work right after I checked "Legacy BIOS Bootable" checkbox using gnome-disks.<br />
<br />
{{Unsigned|13:42, 30 May 2021 (UTC)|Auipga}}<br />
<br />
:Yes, that's what I meant. If it does not work, it should be fixed rather than providing a duplicate instruction without a reason. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:16, 30 May 2021 (UTC)<br />
<br />
== Systemd-networkd systemd-networkd-wait-online.service discussion modifications ==<br />
<br />
I'm not sure why you're reverting my edits.<br />
<br />
You said: "''empty ExecStart is explained in Systemd#Examples''"<br />
<br />
Exactly: Systemd#Examples clearly states "''As another example, in order to replace the ExecStart directive for a unit that is '''not of type oneshot'''''"<br />
<br />
'''systemd-networkd-wait-online''' is a oneshot service. By having the superfluous empty ExecStart you're just confusing people.<br />
<br />
Regarding the file naming, yes the name is irrelevant, but it's generally helpful to non-expert users to stick to canonical naming conventions.<br />
<br />
Please make sure you're on solid ground before reverting edits; you're just discouraging people from engaging with the Wiki. Thanks. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 16:51, 9 June 2021 (UTC)<br />
<br />
:{{man|5|systemd.service}} says: "Unless Type= is oneshot, exactly one command must be given. When Type=oneshot is used, zero or more commands may be specified."<br />
:So when a service is not oneshot, users ''must'' clear ExecStart before adding a modified command in the drop-in file. If a service is oneshot, they ''may or may not'' clear ExecStart, since the service may have multiple ExecStart commands.<br />
:In case of systemd-networkd-wait-online, I don't see why you would want to run multiple instances with different options: one to wait for ''all'' links (which is the default command) and another one to wait for ''any'' link (which is the command in the drop-in example). So clearing ExecStart really makes sense for systemd-networkd-wait-online.<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:44, 9 June 2021 (UTC)<br />
<br />
== Pacman: Install missing dependencies ==<br />
<br />
Hi. [https://wiki.archlinux.org/index.php?title=Pacman&type=revision&diff=690774&oldid=690762 "Pacman" Revision as of 21:50, 4 August 2021 (undo)] - maybe at least put that into [[System_maintenance#Avoid_certain_pacman_commands]]?<br />
<br />
[[User:Galeksandrp|Galeksandrp]] ([[User talk:Galeksandrp|talk]])<br />
<br />
:[[System_maintenance#Avoid_certain_pacman_commands]] already mentions {{ic|-Rdd}}. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:12, 14 August 2021 (UTC)<br />
<br />
== DPMS: "\033[9;0]" ==<br />
<br />
Hi. It seems that you removed {{ic|echo -ne "\033[9;0]"}} from [[Display Power Management Signaling|DPMS]]<br />
<br />
https://wiki.archlinux.org/index.php?title=Display_Power_Management_Signaling&diff=629705&oldid=625073<br />
<br />
[https://www.denx.de/wiki/view/DULG/SwitchOffScreenSaverAndBlinkingCursor A DULG page] and [https://unix.stackexchange.com/a/23636 a U&L post] brought me here.<br />
<br />
May I ask (1) if this method is still working; and (2) where is this escape sequence documented? [not found in {{man|4|console_codes}}]<br />
<br />
Thanks.<br />
<br />
{{Unsigned|05:23, 15 August 2021 (UTC)|PXf}}<br />
<br />
:[[Display Power Management Signaling#DPMS interaction in a Linux console with setterm]] says that setterm works by writing escape codes to the terminal device. The first subsection shows how to reverse-engineer the escape codes. Note that the escape codes are an implementation detail that users should not be concerned with, their documentation is certainly not our job. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:40, 15 August 2021 (UTC)<br />
<br />
== Linux console/Keyboard configuration ==<br />
<br />
Hi, you recently reverted my edit https://wiki.archlinux.org/index.php?title=Linux_console/Keyboard_configuration&oldid=693887. The reason I made that edit, was that I used to put my custom keymap in {{ic|/usr/local/share/kbd/keymaps/personal}} per the previous version of the wiki page. But this doesn't work with ''sd-vconsole'', as it's include files don't get loaded. Your suggested workaround by adding all required files using [[mkinitcpio#BINARIES and FILES|mkinitcpio BINARIES and FILES]] is rather tedious, as all the include files need to be in there, added by hand. This is done automatically by ''sd-vconsole'' if the file was put in {{ic|/usr/share/kbd/keymaps/}}. The reason I made this edit is due to https://bugs.archlinux.org/task/71788. See Giancarlo Razzolini's comment. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:43, 2 September 2021 (UTC)<br />
<br />
:It's just one custom file under {{ic|/usr/local}} and one entry in {{ic|FILES}}. What is so tedious about it? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:37, 2 September 2021 (UTC)<br />
<br />
:: It's not just one file. All the dependencies need to be included too under {{ic|/usr/share/kbd/keymaps/}}. There are quite a few in my case, when I just include ''us.map'' to modify it slightly. See the ''sd-vconsole'' hook script. That script has a part where it finds all the dependencies of a keymap.<br />
<br />
:: * ''/usr/share/kbd/keymaps/i386/include/compose.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/euro1.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-keys-bare.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-with-alt-and-altgr.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/qwerty-layout.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/personal.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/us.map''<br />
:: * ''/usr/share/kbd/keymaps/include/compose.latin1''<br />
<br />
:: [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 12:01, 2 September 2021 (UTC)<br />
<br />
::: I moved this to the talk page so I remember it and others can discuss too. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:18, 4 September 2021 (UTC)<br />
<br />
::: Oh, I see. In that case I suggest we add a tip like this:<br />
::: {{Tip|If you use the {{ic|sd-vconsole}} [[mkinitcpio#Common hooks|mkinitcpio hook]] instead of {{ic|keymap}}, keymaps located under {{ic|/usr/local}} as well as their dependencies from {{ic|/usr/share/kbd/keymaps}} need to be manually specified in the {{ic|FILES}} array in {{ic|mkinitcpio.conf}}. On the other hand, custom files located in {{ic|/usr/share/kbd/keymaps}} will be added automatically when configured in {{ic|/etc/vconsole.conf}}.}}<br />
::: Because this is relevant only for people using the {{ic|sd-vconsole}} hook and otherwise it does not make sense to pollute {{ic|/usr/share/kbd/keymaps}} with custom files.<br />
::: — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:55, 5 September 2021 (UTC)<br />
<br />
== cow_* ==<br />
<br />
Hi Lahwaacz. About the [https://wiki.archlinux.org/index.php?title=Archiso&diff=next&oldid=692981 how/why issue] (there will be no more &lt;!-- --&gt;). What if, for once, that I want to install some large packages after booting archiso, and would not bother modifying packages.x86_64 and building again? [https://www.memesmonkey.com/topic/works+on+my+machine <s>''on my machine''</s>] Darren "Un1Gfn" "[[User:PXf|PXf]]" Ng ([[User talk:PXf|talk]]) 08:18, 12 October 2021 (UTC)<br />
<br />
:It is a subsection of "Tips and tricks", not "Troubleshooting", so it should start with a clear motivation saying ''why'' the tip is useful, rather than an error message that the user has no idea if they will face or not. If you have such description, feel free to rewrite the section. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 05:42, 13 October 2021 (UTC)<br />
<br />
::What about making it a subsection of "[[Archiso#Troubleshooting|Troubleshooting]]" and renaming it to {{ic|partition / too full}}? [[User:PXf|PXf]] ([[User talk:PXf|talk]]) 06:45, 13 October 2021 (UTC)<br />
<br />
:::It's better to motivate it as a tip/trick rather than solve the problem after it happens. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:48, 13 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
(Undo revision 699881 by Oliver (talk) - installing arch-install-scripts does not get the image to "the same footing" as the archiso, even installing something for the first time is not an excuse to violate Help:Style#Package management instructions)<br />
<br />
'the same footing' may be poor choice of wording maybe but it's also not false. You are in a SIMILAR place, not 'exactly identical to the dot' e.g. same footing<br />
<br />
but 'installing something for the first time' is NOT what is going on here really. If we quote the style guide:<br />
<br />
''every Arch user should know pacman's article by memory''<br />
<br />
<br />
The thing is, this is NOT an Arch user yet. They have no idea what's going on, how to do stuff and just want to get started and installed. You can't expect _new_ not-yet-a user, to figure out everything in a daunting installation; by being a smart-bum about it. Yes, the style guide is completely correct on all other points. But I would think that this is the exception, rather then the rule. Help your new users a little. Introduce them gentle with open arms. From a 'first UX kind of way, this is horrible to treat your potentially new users.<br />
<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 17:40, 26 October 2021 (UTC)<br />
<br />
:We use the same convention on the [[Installation guide]] itself. They should read the [[pacman]] page to learn how to install packages as soon as possible, so why not right when they use it for the first time? There is a gentle link to "[[install]]" before the package name, so the clueless user will follow the link and learn something. They will not learn anything by copy-pasting a quick one-liner. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 26 October 2021 (UTC)<br />
<br />
Yes, you ARE right, however; this is the install guide (relatively speaking) Let them install the system first with a gentle nudge; THEN force them to learn stuff :p<br />
<br />
Again, I understand the policy and the reasoning behind it very much so; but it's those first few steps that are the hardest. It's birds vs humans I suppose; birds through their children out of their nests to teach them to fly (or die); Humans raise their children first. Is arch really the 'l337 fly or die, rtfm n00b' kind of distro?<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 18:25, 26 October 2021 (UTC)</div>Oliverhttps://wiki.archlinux.org/index.php?title=User_talk:Lahwaacz&diff=700017User talk:Lahwaacz2021-10-26T18:24:56Z<p>Oliver: /* Install Arch Linux via Docker */ response</p>
<hr />
<div>== bot checking links after move ==<br />
<br />
Hi, re [[Talk:Touchpad Synaptics#adding libinput alternative]]. [[Touchpad Synaptics]] has 100+ backlinks and the more important ones - a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of [[Touchpad Synaptics]] and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:36, 26 September 2015 (UTC)<br />
<br />
:Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a [[UUID]] page, which was later generalized and renamed to [[Persistent block device naming]] and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace <nowiki>[[pacman|Install]]</nowiki> with <nowiki>[[Install]]</nowiki> etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:01, 26 September 2015 (UTC)<br />
<br />
::Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [https://wiki.archlinux.org/index.php/Special:WhatLinksHere/Beginners'_Guide]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:02, 26 September 2015 (UTC)<br />
<br />
== mkosi ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=Systemd-nspawn&diff=0&oldid=491975 revert]: You can use mkosi also to create a container/directory tree (-t directory). So it can do the same and more. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 11:33, 1 October 2017 (UTC)<br />
<br />
:Alright, how is the "more" relevant to systemd-nspawn though? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:30, 3 October 2017 (UTC)<br />
<br />
::Hi, mkosi let's you create images (or directory trees) of various different distributions and allows you to do things like setting the root-password or installing additional packages. systemd-nspawn alows you to boot such images/directory trees. So I thought mentioning mkosi as alternative to manually creating a container with pacstrap or debootstrap would be worth it. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 22:23, 5 October 2017 (UTC)<br />
<br />
== Waking from suspend with USB device ==<br />
<br />
Hi Lahwaacz, thanks for your input on this topic.<br />
Can you help me a bit further, I know the USB host controller and the USB device are different things but I thought that enabling the host controller was not necessary anymore, see [https://www.spinics.net/lists/linux-usb/msg53661.html].<br />
In my case all the {{ic|driver/*/power/wakeup}} are all enabled by default and the {{ic|/proc/acpi/wakeup}} as well.<br />
Anyway I have added a step in my explanations to identify the path awaiting for more clarity.<br />
<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 21:57, 16 January 2018 (UTC)<br />
<br />
:Hi, thanks for the link, it's entirely possible that something changed since the section was written. However, in my case only the keyboard device has wakeup enabled by default: {{bc|<nowiki><br />
$ for f in /sys/bus/usb/drivers/usb/*/power/wakeup; do echo "$f: $(cat $f)"; done<br />
/sys/bus/usb/drivers/usb/1-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/2-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-11/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-12/power/wakeup: enabled<br />
/sys/bus/usb/drivers/usb/3-13/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-4/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb2/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb4/power/wakeup: disabled<br />
</nowiki>}}<br />
:But in practice it seems to wake up the system even without the host controllers enabled for wakeup... It might also depend on some BIOS/firmware settings but if it works by default on most systems then I think the host controller settings could be removed again.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:14, 19 January 2018 (UTC)<br />
<br />
== Are supported local/remote destinations important for choosing a backup program? ==<br />
<br />
You [[Special:Diff/525550|reverted]] my edit adding supported backup destinations to [[Synchronization_and_backup_programs]]. This is puzzling to me. Here are some thoughts:<br />
* if choosing any backup program, the ability to send the backup off-site vs only on a local disk is a key feature consideration. Perhaps *the* key feature: one helps me recover in case my house gets burglarized or burns down, and the other does not. This is a much more important feature consideration than, say, whether the program is written in Go or Mono (something that has a full column). I think it's hard to disagree on that.<br />
* Given this, I am very puzzled you would use the term "useless" in the revert message.<br />
* I assume you didn't like that the table got even bigger (it didn't fit into the layout even before). I don't like it either, but perhaps the revert should have said "can you put this somewhere else, not in this already-too-big table?"<br />
* On a personal note, when I provide feedback or give opinion on somebody else's work, I'd like to be constructive and kind, instead of aggressive and putting people down. Just a thought. Thanks for listening.<br />
<br />
[[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 17:38, 11 June 2018 (UTC)<br />
<br />
:No because you can use any remote back-end with any backup application by just running one command / writing the backups to a [[FUSE]] (if available).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:39, 12 June 2018 (UTC)<br />
<br />
::Hmm, by that reasoning we don't need the Arch package repository, as long as we have source code and makepkg. Or Perl, if we have bash and awk. But even then, and if all the fuse backends existed (I doubt they do), and if it were easy to set all of them up (another thing I doubt), do you indeed believe that running something written to read/write local files will be just as efficient backing up gigabytes of data to a remote repository as something that is specifically optimized for that use case? Note that backing up, say, daily, a typical hard drive via tpyical consumer broadband is still quite a bandwidth challenge in many places today. What about we add this info, and remove (or merge) some other columns to make the table smaller? {{Unsigned|18:08, 12 June 2018|Jernst}}<br />
<br />
:::Your comparisons don't make sense. Mind the slash in my response, you do not need a FUSE implementation, a simple CLI suffices. You do not need to "set all of them up", you only need one. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 18:47, 12 June 2018 (UTC)<br />
<br />
::::If you ever attempt to help a normal user set up a reliably-working off-site backup strategy, think of this discussion. In the meantime, this is all the time I'm going to spend on a discussion that has such repeated gems in it as "makes no sense" without explaining why you think so. Have a nice day. [[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 18:54, 12 June 2018 (UTC)<br />
<br />
== The pip section in [[Python package guidelines]] ==<br />
<br />
Hi, you wanted the warning about using pip or wheels restored but accidentally(?) reverted my whole set of changes. I redid them, leaving the warning in place. – [[User:Flying sheep|flying sheep]] 08:17, 8 March 2019 (UTC)<br />
<br />
:Full revert was intentional, because the "wheel" section is not a full replacement for "pip" because there are packages which don't provide wheel files. As I said in the edit summary, there is no reason to recommend one or the other due to the warning. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 8 March 2019 (UTC)<br />
::That still doesn’t explain why you reverted the first part, that had nothing to do with the pip/wheel section and simple improves the files.pythonhosted.org URLs. I restored that one while we’re discussing the pip/wheel section. And about that: There’s no reason to use pip for anything else, and pip is only used because some people (me included) didn’t understand that you can install most wheels by just extracting them to the correct location. So what do you think is missing from my wheels section that the former pip section had? – [[User:Flying_sheep|flying sheep]] 11:41, 11 March 2019 (UTC)<br />
<br />
:::If you didn't notice, the page includes "guidelines" in the title. So the page should contain only common and recommended ways to do things, not everything that is possible to do. If you think that your way to install "wheels" should be followed by everybody, feel free to discuss it on the talk page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:26, 11 March 2019 (UTC)<br />
::::Well, extracting static archives sounds much more recommended than running pip with like 7 options to make it behave. I added a talk item: [[Talk:Python package guidelines#Remove_pip_section_in_favor_of_wheels_section?]] – [[User:Flying_sheep|flying sheep]]<br />
<br />
== wpa_supplicant ==<br />
<br />
Regarding https://wiki.archlinux.org/index.php?title=WPA_supplicant&diff=577215&oldid=577167, one person ran into this problem in March of this year and spent too much time diagnosing it:<br />
<br />
https://bbs.archlinux.org/viewtopic.php?id=244950<br />
<br />
It took me a few days to find the problem. I want to make sure the next time someone encounters it, they easily find relevant information about what the cause is. Since you've reverted my edits to both netctl and wpa_supplicant, what do you suggest?<br />
<br />
--<br />
<br />
[[User:Pooryorick|Pooryorick]] ([[User talk:Pooryorick|talk]]) 08:24, 18 July 2019 (UTC)<br />
<br />
== F2FS and GRUB ==<br />
<br />
Hello. :) I'm here to address a recent disagreement. I noticed a reversion of my edit regarding the F2FS filesystem, in particular regarding the configuration file to edit (with you representing /boot/grub/grub.cfg and me representing /etc/default/grub). I run F2FS on my daily driver with an encrypted root filesystem and encrypted boot on a separate partition, and have never had to touch grub.cfg. I only automatically generate it. It's possible to use either, but /etc/default/grub would make more sense as a recommendation in my mind because grub.cfg has the potential to be overwritten during updates, whereas /etc/default/grub doesn't. <br />
<br />
If there's a compelling reason to use grub.cfg over /etc/default/grub, please let me know. ^^ I'm always eager to learn more about Arch. I don't want to get in a reversion war so I've left your change untouched for the time being.<br />
<br />
[[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 00:17, 8 September 2019 (UTC)<br />
<br />
:The reason is explained in the section: "If GRUB is used with an unsupported filesystem it is not able to extract the UUID of your drive so it uses classic non-persistent /dev/sdXx names instead." If it does not apply to F2FS, it should be made clear. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:29, 8 September 2019 (UTC)<br />
<br />
::You can specify UUID's in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, so my proposed solution would work for F2FS and other unsupported filesystems, without the burden of manually editing grub.cfg. If there's anything I need to clarify or something else I'm missing, just let me know. :) [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 19:37, 8 September 2019 (UTC)<br />
<br />
:::The {{ic|1=root=}} parameter is not supposed to be in GRUB_CMDLINE_LINUX_DEFAULT, regardless if UUID is used or not. ''grub-mkconfig'' automatically detects the root filesystem and adds the appropriate {{ic|1=root=}} parameter based on GRUB_DISABLE_LINUX_UUID. In any case, your change to the paragraph does not make sense. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:02, 8 September 2019 (UTC)<br />
<br />
::::It could simply be because I use full disk encryption, and adding a kernel parameter for the encrypted disk's UUID is correct in that situation. You're more experienced with contributing to the wiki, so I guess I'll defer to your judgment. It felt like a reasonable edit and solution to me and I don't see the downside to including it in GRUB_CMDLINE_LINUX_DEFAULT. [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 05:38, 9 September 2019 (UTC)<br />
<br />
== dracut executable link ==<br />
<br />
Hello, your last edit on the dracut page (https://wiki.archlinux.org/index.php?title=Dracut&oldid=596388) that undid my 'Link to direct "make executable" section for executable link' commit states: "the redirect executable points exactly to that section", but it doesn't. Following the [[executable]] link just points to the top of the Help:Reading page.<br />
<br />
{{unsigned|17:06, 28 January 2020|Krathalan}}<br />
<br />
:In that case your browser probably does not work correctly, because the redirect [https://wiki.archlinux.org/index.php?title=Executable&redirect=no really points to the section]. Or MediaWiki, there was a bug several years ago... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 28 January 2020 (UTC)<br />
<br />
:: How strange... thanks for pointing that out. It does indeed appear to be some issue with my Firefox configuration. [[User:Krathalan|Krathalan]] ([[User talk:Krathalan|talk]]) 19:51, 28 January 2020 (UTC)<br />
<br />
== Getting install.php work in DokuWiki ==<br />
<br />
Hi, than you for having undone my contribution and pointed to the right solution on [[Dokuwiki#Configuration]]. Indeed I had read this solution before, but I was misled by the condition "if you are using lighttpd or nginx and your PHP version is lower than 7": as I use Apache with php v. 7.4.3 I didn't take it into account. Do you know what a correct rephrasing could be? Maybe it should be deleted?<br />
<br />
Also, I think that, at the end of this same section, one should add something like "verify that {{Pkg|php-gd}} is installed and restart {{ic|php-fpm.service}}".<br />
<br />
Naturally I can do it myself, but I prefer to ask before.<br />
[[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 17:31, 19 February 2020 (UTC)<br />
<br />
:Hi, apparently it depends on whether you had {{ic|open_basedir}} set previously or not. I've changed the page, feel free to update the gd extension. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:16, 19 February 2020 (UTC)<br />
<br />
::Thank you! However, while, I didn't have {{ic|open_basedir}} set previously, I couldn't access ''install.php''. I suspect there is another thing to do, since the configuration editor in DokuWiki complains that it cannot modify the configuration files although ownership and permissions are correctly set for the relevant symlinks, directories and files, and so is {{ic|open_basedir}}. However I can edit my pages. Maybe a return from a new user with a fresh installation would be more useful, though. [[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 08:20, 20 February 2020 (UTC)<br />
<br />
== Dead link in Simple stateful firewall#See Also ==<br />
<br />
Hi, Jakub. I am about [https://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&diff=599725&oldid=599717 this] edit. I tried to follow that link one more time and it is not require entering captcha. I am not see any content limitations and my colleague (he uses Tor) does not see them too. I am not sure how it works, so I leave it on your descision. -- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 14:29, 1 March 2020 (UTC)<br />
<br />
:Well, maybe it depends on the location from which the request comes. But I don't know how it works either... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:33, 1 March 2020 (UTC)<br />
<br />
::my guess is it returns captcha for crawlers only -- [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 01:59, 2 March 2020 (UTC)<br />
<br />
:::I'm getting it in my browser... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 2 March 2020 (UTC)<br />
<br />
== SystemD user units depending on graphical session ==<br />
Hi,<br />
regarding reverting my addition to [[Systemd/User]], could you please explain why? I referenced [[https://www.freedesktop.org/software/systemd/man/systemd.special.html]] which directly contradicts what you said in your summary.<br />
<br />
{{unsigned|19:53, 5 May 2020|Fuero}}<br />
<br />
:The note in [[Systemd/User#How it works]] still applies - systemd services are never per-session, but per-user. The service does not magically get the correct DISPLAY or WAYLAND_DISPLAY variable, it does not work if you have multiple sessions per user, etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:45, 6 May 2020 (UTC)<br />
<br />
== Plymouth ==<br />
<br />
Actually with just Plymouth it does not work properly. Even 0dd17y had the same issue in https://bbs.archlinux.org/viewtopic.php?id=220900.<br />
<br />
The reason I did not file a bug report is that it is anyway fixed in the git version and the latest release (0.9.4) is around 2 years behind master<br />
<br />
{{unsigned|09:50, 6 May 2020|M.Srikanth}}<br />
<br />
:So if you don't have to file a bug report, add a full troubleshooting entry or at least properly reference your inline note instead of resorting to plain "if that does not work, try this instead". -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:15, 6 May 2020 (UTC)<br />
<br />
== [Bitcoin core] build the code and run the test suites ==<br />
<br />
Hello,<br />
<br />
This week, I managed to build the Bitcoin code and run all the test suites with the help of this page: https://jonatack.github.io/articles/how-to-compile-bitcoin-core-and-run-the-tests<br />
<br />
Archlinux has two particularities:<br />
* being in rolling release, it takes to manually use the library {{ic|Berkeley DB (BDB) v4.8}}<br />
* the {{ic|/tmp}} directory is by default limited to half the size of the Ram<br />
<br />
For these reason, maybe it could be interesting to have a page in the wiki to explain how to build the Bitcoin core?<br />
<br />
Cheers,<br />
<br />
Thomas<br />
<br />
[[User:Thomasb|Thomasb]] ([[User talk:Thomasb|talk]]) 20:29, 9 May 2020 (UTC)<br />
<br />
:I don't think that this is useful. There is the {{AUR|bitcoin-core-git}} package and nothing more should be needed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:53, 26 May 2020 (UTC)<br />
<br />
== Double linefeed results in extra line ==<br />
<br />
If you look at templates that end with double linefeed before noinclude this would result in extra line in resulting page.<br />
<br />
It may be a minor point but since you are perfectionist about wikitext I should mention this is a tradeoff and it results in slightly worse result.<br />
<br />
Removing just one linefeed removes the problem while still allowing it to not jumble all the tags into same line.<br />
<br />
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:30, 11 May 2020 (UTC)<br />
<br />
:If this is about [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=next&oldid=612179], the spaces I added back are not included when the template is used elsewhere, because the spaces are inside the noinclude tags. The extra space is only on the template page itself, but it does not result from template inclusion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:41, 11 May 2020 (UTC)<br />
<br />
::OFC, I mean the template page render has extra line. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 21:21, 11 May 2020 (UTC)<br />
<br />
:::I agree with [[User:Svito|Svito]], isn't it good to delete the extra blank lines? -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 05:39, 12 May 2020 (UTC)<br />
<br />
::::OK, let's do it. [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=616382&oldid=612181] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:47, 26 May 2020 (UTC)<br />
<br />
== Re: lighttpd: remove python2 version ==<br />
<br />
Instead of removing the example we could as well add an example using a Python3 library like https://pypi.org/project/flup6/.<br />
<br />
{{unsigned|15:23, 18 May 2020|Gruentee}}<br />
<br />
:Feel free to add it if you find it useful. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:56, 18 May 2020 (UTC)<br />
<br />
== Xbindkeys removal ==<br />
<br />
Hi, just wondering why you [https://wiki.archlinux.org/index.php?title=Xbindkeys&diff=617675&oldid=617670 removed my edit] from [[Xbindkeys]]? The xbindkeys page has a number of quick tips but no mention of how to bind anything to the Print Screen key so I thought it would be useful to add. -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 02:27, 3 June 2020 (UTC)<br />
<br />
:Giving examples for all keys on the keyboard is useless, there is [[Xbindkeys#Identifying keycodes]] which teaches how to find the keycodes and keysyms of any key. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 3 June 2020 (UTC)<br />
<br />
:: So how come you left the examples for the volume up/down and brightness? What is different between those examples and a screenshot example? Aren't more examples better to save people from hunting all over the place trying to piece things together themselves? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 14:03, 4 June 2020 (UTC)<br />
<br />
:::The difference is that when it comes to volume control, there are 1 or 2 options for the 99% most common cases, but for screenshot taking there are dozens of different options. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:15, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for edit to XDG Base Directory page regarding python_history ==<br />
<br />
I understand the justification for reverting the change I made, however I would like to point out that similar entries on the page (such as Maven) also have instructions for what contents to put in files (even though there is native documentation for those settings). Additionally, it took me a bit of re-reading on the linked Python documentation to reason out how the documentation's example needed to be modified, since it's not clear from the Python documentation whether placing such code in the PYTHONSTARTUP file will actually ''override'' the default behavior. [[User:Varriount|Varriount]] ([[User talk:Varriount|talk]]) 20:44, 20 June 2020 (UTC)<br />
<br />
:Even maven's note can be [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=631704&oldid=631630 shortened]. The notes in the table must be as short as possible, there is no place for extended explanations or long code snippets like in the upstream documentation. If the Python's documentation is not clear enough, I don't think any note in a massive convoluted table will ever be better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:47, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for Backlight page ==<br />
<br />
Hi, you reverted my change to [[Backlight]] page that mentioned WIP patches for controlling OLED panel brightness. I don't really understand justification for reverting it since currently the page says that OLED brightness can be controlled only by changing gamma ramp. That is wrong - since it's not the only way - these panels can control brightness with a PWM. Moreover controlling brightness with gamma ramp is not optimal - it essentially reduces dynamic range, i.e. at 50% you have 7 bits per pixel, at 25% - 6 bit per pixel, etc. That results in banding artifacts at lower brightness level.<br />
<br />
As far waiting for the patches to be merged before mentioning it there - it'll take ~3-6 months (yes, that's the process) and I haven't found *any* reference to these changes on the internet - everyone recommends using gamma ramp instead of fixing it properly. I'm absolutely sure that having information about these patches would not hurt [[User:Anarsoul|Anarsoul]] ([[User talk:Anarsoul|talk]]) 15:56, 30 June 2020 (UTC)<br />
<br />
:Linking to a repo which which has 2 custom commits on top of some arbitrary development version of the Linux kernel tree is not helpful for users. Nobody will compile directly from this repo which is already significantly outdated compared to recent kernel versions and there is no indication if the patches actually work with newer (or older) kernels. We can mention the PWM control as a general concept though. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:32, 12 August 2020 (UTC)<br />
<br />
== Automatic template correction ==<br />
<br />
Per [[Help:Template#Style]], templates should be used with the capitalization shown in the examples in their pages, so {{ic|&#123;{AUR&#124;...}} is correct, while {{ic|&#123;{aur&#124;...}} is not.<br />
<br />
However, there are pages that don't respect that rule (e.g. [[Android_Debug_Bridge]] until recently).<br />
<br />
I beleive this correction should be easy to implement using a bot. What do you think?<br />
<br />
{{unsigned|07:24, 25 August 2020|Relrel}}<br />
<br />
:Yes, this should be easy, but the bot should not make a huge amount of simple style-only changes - they should be combined with corrections for more complex rules. Anyway, there is an idea to create a [https://github.com/lahwaacz/wiki-scripts/issues/22 style linter] for the ArchWiki rules. Would you like to help? ;-) – [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:21, 25 August 2020 (UTC)<br />
<br />
== Failed to create tun device ==<br />
<br />
I don't understand your reason for [[https://wiki.archlinux.org/index.php?title=NetworkManager&diff=0&oldid=634880 removing my section in NetworkManager]]. Could you elaborate?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 07:40, 11 September 2020 (UTC)<br />
<br />
:You can't use [[systemd-networkd]] and [[NetworkManager]] at the same time. Even if you don't have any ''.network'' file for systemd-networkd, you can't solve NetworkManager's problems with systemd-networkd. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:43, 11 September 2020 (UTC)<br />
<br />
::Ok, thanks, in this case it solved the error I got. Now the VPN works. Do you have an idea about how to solve it without systemd-networkd?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 22:27, 11 September 2020 (UTC)<br />
<br />
:::You should really fix the permission problem for {{Pkg|networkmanager-openvpn}}. The tun interface should be managed by OpenVPN which needs rights to create it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 12 September 2020 (UTC)<br />
<br />
::I don't think this statement is entirely correct. [[systemd-networkd]] and [[NetworkManager]] can happily co-exist together if they are managing different interfaces. I unfortunately don't have a reference to point to this, but I came across this being mentioned a couple of times on forums. I personally use [[NetworkManager]] on my laptop to handle wifi, while [[systemd-networkd]] is in control of virtual ethernet and bridges for all my [[systemd-nspawn]] instances. [[User:Romstor|Romstor]] ([[User talk:Romstor|talk]]) 03:24, 12 September 2020 (UTC)<br />
<br />
== [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&oldid=636526/ XDG Base Directory]: Undo revision 636525 ==<br />
<br />
Dear Lahwaacz,<br />
<br />
maybe my changes were to rushed and from my point of view only. But I have two points to consider:<br />
<br />
# If I put the quotes around my vimrc and source it from my .bash_profile, I get the vim-error E471 (Argument required). Without quotes, this doesn't happen. So this change based on experience.<br />
# The rtp should includes directories, which are needed at runtime. (in plain vim e.g. ~/.vim). This is not a typical configuration directory. My mistake was, that I supposed that everyone put their vim plug-ins in $XDG_DATA_HOME and not in $XDG_CONFIG_HOME, because from my point of view a plug-in doesn't belong to the configuration. Maybe it is a good idea to add a remark, which explains the addition of $XDG_CONFIG_HOME to the rtp.<br />
<br />
[[User:Grrr|Grrr]] ([[User talk:Grrr|talk]]) 13:53, 26 September 2020 (UTC)<br />
<br />
# Quotes are there because $XDG_CONFIG_HOME may contain spaces.<br />
# It's not only about quotes - the runtimepath has subdirectories for color schemes, keymaps, autoload scripts etc.<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 26 September 2020 (UTC)<br />
<br />
== Readability in Wiki ==<br />
<br />
I noticed that you and the other admins and moderators often want sentences to continue endlessly, without line breaks.<br />
For example in the introduction of [[Wayland]].<br />
<br />
I think it would be better to have more seperated sentences, so it is easier to read and "important" information is easier visible for people.<br />
I don't know who is responsible, but maybe some options in MediaWiki (or whatever this wiki software is) could be changed as well, to make make line breaks etc. easier and reduce the height-space (if you know what I mean) between sentences, so it looks better, even though line breaks are used.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:38, 15 October 2020 (UTC) G3ro<br />
<br />
:I don't know exactly what you mean. Is it about the readability of the rendered HTML or the "source code" of the page? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:15, 15 October 2020 (UTC)<br />
<br />
:: Well I guess it can be about both. But mainly it is about what people see on the page.<br />
:: There are three seperate topics I mentioned:<br />
<br />
:: 1. Use line breaks: I would like to use more line breaks, because if you have long sentences that are written after each other without line breaks, it gets "harder" to recognize when the next sentence starts.<br />
:: While I agree to what you said somewhere, that sentences that belong directly together, should be written in one "paragraph", it would be useful for sentences that cover (slightly) different "topics" to be visibly parted.<br />
<br />
:: 2. Adjust margin options: I notice that when line breaks are used, there is a vertical space added between two sentences. Just like in this post. If you would use line breaks more often, this is a little too much spacing in my oppinion.<br />
<br />
:: 3. Potential options to make line breaks easier: It would be very convenient if a line break in the source code would lead to a line break in displayed text as well, instead of needing to add an empty line.<br />
<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:33, 15 October 2020 (UTC) G3ro<br />
<br />
:::OK, now I understand. I agree that splitting different topics usually improves legibility, but they should be split into separate paragraphs and not just by line breaks (e.g. using the &lt;br> tags). Paragraphs are semantic units whereas line breaks inside a paragraph are usually typographic errors.<br />
:::Also note that such splitting alone may not be enough to improve the text flow. For example, if we consider the intro for [[Wayland]], the second sentence about XWayland would not constitute a good paragraph - it is just a plain statement and the new topic is not nicely introduced. Ideally, you'd split the topic and make some wording changes for the second paragraph.<br />
:::As for the margin options, that is the difference between paragraph splitting and non-semantic line breaks. In my opinion, the styling is correct in this respect, as paragraphs should be discernible. You mentioned that you like line breaks to easily recognize where a sentence ends - but reading should be based on whole paragraphs, not sentences. There should be no reason to skip anything in the middle of a paragraph, otherwise it should be probably split into multiple paragraphs or otherwise rephrased.<br />
:::If you find it hard to follow a long sentence horizontally on a wide screen, we might consider enforcing some maximum width for the whole content. I think the readability would be better, since there would be more top-to-bottom eye movement at the cost of left-to-right-and-back.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:59, 15 October 2020 (UTC)<br />
<br />
== Xorg parentheses ==<br />
<br />
I actually think that X(org) is very useful to imply that it is one and the same thing.<br />
<br />
It might even be more confusing now, as we use both Xorg and X, because the wiki title and the package titles are Xorg.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:30, 17 October 2020 (UTC) G3ro<br />
<br />
:Well the conventions should be established on the [[Xorg]] page, not anywhere else... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:36, 17 October 2020 (UTC)<br />
<br />
:: Imo the conventions are established by upstream and they use a wide variety of X, X.org, X(org), Xorg etc.<br />
:: As I said I always prefer X(org) because then it is clear, that both are same thing.<br />
:: But ultimately it's your decision. <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:43, 17 October 2020 (UTC) G3ro<br />
<br />
:::When upstream is not capable of making a unambiguous decision, it makes sense that other projects pick some option and stick with it wherever they can to keep at least some consistency. So for this wiki, pages should use the same style as the [[Xorg]] page. But feel free to start a discussion about this in [[Talk:Xorg]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:56, 17 October 2020 (UTC)<br />
<br />
== SSHFS - systemd edit ==<br />
<br />
The edit was removed because "there is no advantage over using fstab entries".<br />
<br />
Is not only about the dis/advantages of the systemd option, is about that it is another possibility to achieve the task, that is why it was created in another level and the fstab section was left alone.<br />
<br />
Reconsider the edit as it presents another option which people can use.<br />
<br />
[[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 16:22, 22 October 2020 (UTC)<br />
<br />
:There is no need to use anything else, fstab just works well enough. Configuring mounts with systemd services is not a good idea - it is much more bloated than fstab and not the right tool for it. If anything, a different type of systemd units should be used: {{man|5|systemd.mount}}. But creating the mount units manually is still pretty useless since everything can be configured in fstab and systemd will generate the unit for you. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:22, 22 October 2020 (UTC)<br />
<br />
:: It is about the ability to use the user's .config file and all the proper options that are saved there. Also systemd gives the possibility to use different targets, so the user could mount it when an specific user logs in or when a graphical session starts. I could argue that bad a modification of fstab could lead to a system that doesnt boot, but such poorly configured systemd unit file just fails and the system is fine. Just give the user the information and let it decide what they can use depending on their use case. [[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 08:08, 24 October 2020 (UTC)<br />
<br />
:::You can configure systemd targets in fstab using the {{ic|x-systemd.wanted-by}} and {{ic|x-systemd.required-by}} options, there are also {{ic|nofail}} and {{ic|noauto}} options. Please read the {{man|5|systemd.mount}} manual.<br />
:::Using hosts from the user's {{ic|.ssh/config}} is the only thing which is not possible with fstab, but this does not warrant using the wrong tool for the task. Simple copy the full {{ic|user@hostname}} into fstab and you're done.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:47, 24 October 2020 (UTC)<br />
<br />
== [[Self-encrypting drives]] ==<br />
<br />
Hi, I'd like to respectfully disagree with the rollback. It's specific to sedutil that with most commands you need to input /dev/nvme0 (when encrypting the device) but for the sleep commands it requires /dev/nvme0n1 or it fails with a very unspecific error (Error saving the password to the kernel errno = 25), as found out in the discussion https://github.com/Drive-Trust-Alliance/sedutil/issues/90<br />
<br />
All in all I believe that it is important to keep this piece of information which was found out in a long discussion between the reporter and the developers. I ran into it and I believe many people may run into it, considering most of the new SSD will be NVMe. Best, [[User:Przemub|Przemub]] ([[User talk:Przemub|talk]]) 13:34, 28 October 2020 (UTC)<br />
<br />
:OK, then it makes sense. But it should be probably explained before, not in the section about the sleep command. Also please add the link to the note as a reference. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:27, 28 October 2020 (UTC)<br />
<br />
== Nvidia Installation ==<br />
<br />
The whole guide is unnecessary long and overcomplicated formulated.<br />
Shorter is better, most people will know their graphic card for example, so the determination etc. is only optional.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:21, 10 November 2020 (UTC) G3ro<br />
<br />
:Moving some info to some other page and leaving a tip behind does not make it shorter, but harder to follow. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:36, 10 November 2020 (UTC)<br />
<br />
== Btrfs layout ==<br />
<br />
Hi, Lahwaacz<br />
<br />
Thanks for maintaining [[Snapper]]! However I think the layout is not openSUSE specific and beneficial to all btrfs users. Can you elaborate your reason of undoing the edits? IMO the previous 'simple layout' complicates the rollback procedure.<br />
<br />
Cheers,<br />
[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 07:26, 3 December 2020 (UTC)<br />
<br />
:It is not overcomplicated, it is just doing things right. You can read about that in the forum thread, see the first note in [[Snapper#Suggested filesystem layout]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:24, 3 December 2020 (UTC)<br />
<br />
::Anyway I've moved the guides to my user page. It's not that I haven't read the 5-year-old forum post, it's that before the current layout I followed that post and resulted in a not fully rolled-back system. That post also sourced (then current) information from openSUSE. openSUSE has since massively overhauled the layout, as I pointed out in an edit you undid earlier.[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 09:02, 3 December 2020 (UTC)<br />
<br />
::Since last message I've extensively documented the new layout at [[User:I2Oc9/Btrfs_subvolumes]] and [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption]]. Have a look for yourself. Nothing new really, but IMO [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my take]] is much more simpler and complete than the supposedly [[Snapper#Restoring_/_to_a_previous_snapshot_of_@|simpler one]]. That one does not leverage native {{ic|snapper rollback}} or {{Pkg|grub-btrfs}}, among other things. I strongly suggest you try if you have time. [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 11:55, 3 December 2020 (UTC)<br />
<br />
::Actually if you look closely, none of [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my recovery methods]] is specific to [[User:I2Oc9/Btrfs_subvolumes#A_new_kind_of_layout|the new 'complex' layout]], it will work totally fine with the old one. I just don't think moving @ around in live environment is appropriate.<br />
<br />
::On the other hand, the layout recommendation has been updated by openSUSE [https://en.opensuse.org/SDB:BTRFS], why stick with the old one? [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 12:37, 3 December 2020 (UTC)<br />
<br />
:::The main reasons why I reverted your edits on the [[Snapper]] page are: 1) it was a huge change which was not discussed previously as required by [[ArchWiki:Contributing#The 3 fundamental rules]], and 2) it has some elements which do not apply to Arch (see below). If you wish to propose a better layout of the subvolumes, it should be discussed in [[Talk:Snapper]] first. Your user pages would serve as great drafts.<br />
:::Note that the current suggested layout is not ''flat'' in the sense of [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|your section]] - it has a separate subvolume for {{ic|.snapshots}} so it does not lead to the recursive mess. So your proposed layout seemed very similar to the current suggested layout. The real difference is which subvolume gets mounted at {{ic|/}}, but I did not find it explained anywhere on the Snapper page before I reverted the changes (I get it now from your user page). I also did not find a proper documentation of the openSUSE's layout - it seems to be just the product of their installer and the documentation only deals with the result, saying at most that [https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-snapper.html#sec-snapper-snapshot-boot the subvolume configuration must not be changed] for rollbacks to work.<br />
:::Now the openSUSE-specific elements: some Arch packages actually install software into {{ic|/opt}}, so the recommended layout should not suggest a separate subvolume for this path. Even more importantly, the pacman database is located at {{ic|/var/lib/pacman/local/}} and it must be rolled back along with the system, so there should be no separate subvolume for {{ic|/var}}. Instead, users should be encouraged to create (even nested) subvolumes for specific data directories under {{ic|/var}}, such as {{ic|/var/log}}, {{ic|/var/tmp}}, {{ic|/var/cache/pacman}}, {{ic|/var/lib/machines}}, etc.<br />
:::Finally, the suggested layout should not be GRUB-specific, there should be no recommendations regarding a boot loader. Sure it is useful to include non-trivial tips, but people may actually use a different boot loader.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:31, 4 December 2020 (UTC)<br />
<br />
::::Thanks for your detailed reply. I admit that I'm not knowledgeable on the intricate differences between distributions and shouldn't have made the changes without properly discussing them first.<br />
::::Yes, I get that the current layout is not [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|the one described in this section]] and indeed properly separates {{ic|/.snapshot}} and {{ic|/}}. The layout I proposed attempts to add some "niceties" such as supporting multi-distribution installations (complex and unnecessary, I agree) and bring the openSUSE layout here, which is a mistake, as you've pointed out.<br />
::::As for GRUB, since I use LUKS all the time and it's the only bootloader supporting encrypted {{ic|/boot}} on Btrfs on LUKS1, I really didn't think of any other possibilities.<br />
::::I will incorporate your recommendations to my user page and add a new section in [[Talk:Snapper]] pointing to those pages.<br />
::::Cheers -- [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:09, 4 December 2020 (UTC)<br />
<br />
:::::I've adopted [[Install_Arch_Linux_on_ZFS#System_datasets|Archlinux Root on ZFS layout]] to [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Create_subvolumes|my proposal]]. [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:56, 4 December 2020 (UTC)<br />
<br />
== Reflector Revert ==<br />
<br />
Hi Lahwaacz, about your [https://wiki.archlinux.org/index.php?title=Reflector&oldid=643749 revert], it seems like there's precedence for including AUR packages that replicate the code on the wiki. For example, in [[dash#Relinking /bin/sh]].<br />
<br />
In addition, I believe that there's value for linking the AUR package because it allows a simpler user experience where the AUR package is maintained for them. That way, if it is ever updated, they can easily fetch the update instead of religiously checking the wiki page (which most users probably don't do).<br />
<br />
Thanks!<br />
<br />
[[User:Denton-l|Denton-l]] ([[User talk:Denton-l|talk]]) 01:52, 7 December 2020 (UTC)<br />
<br />
:That precedence was only created by [https://wiki.archlinux.org/index.php?title=Dash&type=revision&diff=561587&oldid=518398 yourself]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 5 May 2021 (UTC)<br />
<br />
== firefox zoom ==<br />
<br />
"no reason to zoom manually, see HiDPI)" - fractional scaling doesn't work [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 26 December 2020 (UTC)<br />
<br />
:That should be explained in [[HiDPI#Firefox]] anyway. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:48, 26 December 2020 (UTC)<br />
<br />
::it's good to have this mentioned somewhere clearly so people know about it before they say "fonts on linux suck" [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 15:51, 29 December 2020 (UTC)<br />
<br />
== Intel GVT-g edits ==<br />
<br />
Hello Lahwaacz,<br />
<br />
I have noticed that you reverted one of the edits I have performed on [[Intel_GVT-g]].<br />
<br />
About this revert: [https://wiki.archlinux.org/index.php?title=Intel_GVT-g&oldid=648062 Windows problems are out of scope]<br />
<br />
While I understand that the ArchWiki is about ArchLinux, this article in particular mentions Windows in the introduction, and already includes another troubleshooting point about Windows. The issue I have encountered with the black bars is somewhat common, as I have found other people discussing it online, and I really fail to see why not including this piece of information in this article would be better than including it.<br />
<br />
Please, let me know your thoughts. If you think that the point can be improved, I will be happy to do that.<br />
<br />
Ciao,<br />
<br />
[[User:Wilcomir|Wilcomir]] ([[User talk:Wilcomir|talk]]) 09:14, 3 January 2021 (UTC)<br />
<br />
:Well, the existing section about a Windows problem is actually solved by configuring the Linux host. I think anything involving configuration or installation of programs in Windows is not appropriate for long troubleshooting sections. At most, they could be mentioned in a short reference to other sites which describe the problem in detail. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:34, 3 January 2021 (UTC)<br />
<br />
== <s>XDG configuration for Vim</s> ==<br />
<br />
Hi Lahwaacz,<br />
<br />
You have reverted the updated Notes for Vim on [[XDG Base Directory]], because "copy-pasted from a blog post".<br />
<br />
The problem is, not only is the configuration presented currently also copied from a blog post too, but is already 10 years old.<br />
<br />
Would it be OK, if we bring back the more up to date version? Or at least remove the obsolete one and leave link to newer?<br><br />
(Although I think a copy on wiki would be beneficial in case my blog ceases to exist)<br />
<br />
[[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 02:05, 12 January 2021 (UTC)<br />
<br />
:OK let's close this. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:49, 29 August 2021 (UTC)<br />
<br />
== Root on ZFS draft ==<br />
<br />
Hi, I submitted [https://github.com/openzfs/openzfs-docs/pull/104 a Root on ZFS draft] to official doc repo.<br />
<br />
In the draft, the following directories are separated from root filesystem:<br />
home,root,srv,usr/local,var/log,var/spool,var/tmp<br />
<br />
Is this appropriate for Arch Linux? Or do you have any suggestion on the draft?<br />
Any comment is appreciated.<br />
[[User:M0p|M0p]] ([[User talk:M0p|talk]]) 01:28, 23 January 2021 (UTC)<br />
<br />
== Re: undo GRUB - Common installation errors ==<br />
<br />
Concerning your undo of [https://wiki.archlinux.org/index.php?title=GRUB&diff=next&oldid=649799 Add the error message `Could not prepare Boot variable: No space left on device`)]<br />
Is there a better place to for this Information? One can find the solution in various forums, but I thought it could be helpful to have it in this wiki somewhere. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 12:51, 25 January 2021 (UTC)<br />
<br />
:The error message is not specific to the {{ic|/sys/fs/pstore/}} filesystem (which does not even seem to be used by default on Arch...) Where did you find that? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:16, 25 January 2021 (UTC)<br />
<br />
::I did not find anything Arch specific, but this post about Debian helped: [https://donjajo.com/fix-grub-efibootmgr-not-set-variable-no-space-left-device/ Post]. I also found something about [https://askubuntu.com/questions/1072618/could-not-prepare-boot-variable-no-space-left-on-device-grub-install-error-ef /sys/fs/efi/efivars/dump-*] The problem is that the actual efi-partition does not seam to be the problem, there is more than 70% space left. If there is better information to guide the user in the right direction that wuld be more helpful. This is what I found worked, but I admit that I don't know much about how grub operates. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 16:20, 25 January 2021 (UTC)<br />
<br />
:::This wiki ''is'' Arch specific so old posts about Debian or Ubuntu do not apply. Even if they did, this is hardly a ''common'' installation problem. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:29, 26 January 2021 (UTC)<br />
<br />
::::I know that, and would not have put it there if it didn't occur on my Arch Linux installation. If this is something that should not be documented in this wiki, I understand that. Is there any other place you would recommend? An issue for grub-install maybe? [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 22:24, 26 January 2021 (UTC)<br />
<br />
== Kernel Compilation time ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Kernel&diff=next&oldid=650896 link]<br />
<br />
I don't think we should judge information by what is obvious to experts.<br />
People might have experience with compilation of other programs, which mostly is fast, and then there is the kernel which takes forever to compile.<br />
I think it does not hurt anyone to make people aware of it.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:03, 6 February 2021 (UTC)<br />
<br />
:It is an unnecessary information without a definite answer which can even be [https://html.duckduckgo.com/html?q=how%20long%20does%20it%20take%20to%20compile%20Linux%20kernel searched elsewhere]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:23, 6 February 2021 (UTC)<br />
<br />
:: I disagree, with that argument nearly any tip and note is unnecessary. These things are intended to inform users about things that should be taken into consideration and that are different from the norm.<br />
:: Also do you search for the compilation time for every program you intend to compile? I don't.<br />
:: Furthermore this info is included, why not tell it to people directly on the start, so they don't read over it? <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:36, 6 February 2021 (UTC)<br />
<br />
:::If someone wants to compile the Linux kernel, they should obviously expect that it will take ''some time''. Stating that it "can take up to several hours" does not make sense without referring to a specific hardware. Obviously, it will take much longer on a poor laptop than on a powerful workstation with a many-core processor, but people can assume that themselves. Without a reference to a specific hardware, the note is unnecessarily discouraging because the compilation can be as fast as some tens of minutes - it is by far not the most expensive package to compile...<br />
:::As you said, people can find better notes later along with advices to enable parallel build etc. which is all that's needed IMO.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:03, 6 February 2021 (UTC)<br />
<br />
== Wayland style ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Wayland&diff=prev&oldid=650979 link]<br />
<br />
I think in the old version it was much easier to read the "source code", so I don't see why there can't be spaces between it.<br />
Things shouldn't be complicated more than necessary.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:11, 6 February 2021 (UTC)<br />
<br />
:Most templates on the wiki are written without spaces around the |. When we [https://github.com/archlinux/archwiki/pull/32 switch the editor], there will even be syntax highlighting. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:25, 6 February 2021 (UTC)<br />
<br />
== Bluetooth keyboard ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php/Bluetooth_keyboard link]<br />
<br />
On your last change you said "not specific to keyboards, all of this is already mentioned on the Bluetooth page", the point is that this is extremely relevant for bluetooth keyboard since it is required to perform the login! If this little piece cannot be duplicated I would suggest at least to leave a link saying "If you want to autoconnect at boot please refer to...". I'm new here and I would not touch it further, but please evaluate the suggestion (this is because after reading bluetooth keyboard page and not finding the solution I had to look for it on forums)<br />
<br />
{{unsigned|21:17, 20 February 2021|Stevexyz}}<br />
<br />
:Well, basically the whole page is flagged to be merged with the main [[Bluetooth]] page, so it's expected to be incomplete. Other tips may always be found on a more general page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:40, 21 February 2021 (UTC)<br />
<br />
== Re: Steam Needs to be online error ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Steam/Troubleshooting&diff=next&oldid=653073 link]<br />
<br />
The problem here is that DNS resolution in general works already (yes even outside browsers), i.e. <br />
<br />
dig media.steampowered.com<br />
<br />
would run successfully, but the Steam client couldn’t resolve it. The DNS request from 'dig' shows up in my nameserver’s log, the one Steam should send doesn’t. This indicates it might indeed a problem specific to Steam, and it’s not as easy as just say "go fix your DNS resolution", as it already may work correctly for everything but Steam.<br />
<br />
Additionally, at no point does [[Domain name resolution]] even mention nscd, so you effectively removed a fix/workaround for the problem from the Wiki. So I was definitely not "duplicating an article" here. [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 08:12, 22 February 2021 (UTC)<br />
<br />
:Could I please hear your opinion on this? I’d be happy to just add something along the lines of "if you made sure DNS resolution works but Steam still can’t resolve it, try additionally enabling the nscd service" to the Steam troubleshooting page. Unfortounately I don’t know why running the service helps, but I’d still like to give others an easier time finding this solution than I had myself. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 09:15, 28 February 2021 (UTC)<br />
<br />
::Hi, I'm sorry for the delay. Could you test if using a different program for DNS caching (e.g. [[systemd-resolved]]) instead of {{ic|nscd.service}} fixes the problem? If not, then it's probably not due to DNS - {{man|8|nscd}} actually caches more than just DNS. Also if you have a reference to some website where you found about nscd, it would be nice to add it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 28 February 2021 (UTC)<br />
<br />
:::No worries. Using [[systemd-resolved]] for DNS resolution (and caching I guess, I wasn’t aware it does that, too) was a thing I did try, but that didn’t fix it for me. The place I found out about nscd fixing it was actually the [https://bbs.archlinux.org/viewtopic.php?id=263356 Arch forums]. When I search the web for Steam in combination with nscd, all I can seem to find are more forum entries of people that don’t know why that fixes it either. I can try a bit to find out what nscd does to make it work, but I’m not too confident I will be successful. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 14:51, 28 February 2021 (UTC)<br />
<br />
::::Okay, so {{ic|nscd}} allows to [https://man7.org/linux/man-pages/man5/nscd.conf.5.html dis-/enable caching per service], and it’s indeed enabling it for {{ic|hosts}} that makes it work. That’s weird though, since [[systemd-resolved]] has caching enabled by default, and using it for resolution didn’t make {{ic|steam}} work for me. Leads me to think that I didn’t set it up correctly, although resolving via {{ic|dig}} *did* work. Since [[steam]] depends on [[Name Service Switch]], I tried resolving using {{ic|getent}} manually with nscd disabled, but that worked while steam did not. I’m not really sure what to make of this, since I have no idea how this low level networking/resolving stuff works really. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 15:39, 28 February 2021 (UTC)<br />
<br />
:::::Hmm, I don't know the details either. Steam needs the multilib packages so maybe that's part of the problem. Could you add your findings to the section and use [[Template:Expansion]] for the missing details? Maybe someone can figure it out. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:44, 28 February 2021 (UTC)<br />
<br />
::::::Sure, I can do that. I’ll probably need a minute to figure out how to use the template though, but I should have the time later today. Thanks for your input on this. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 17:56, 28 February 2021 (UTC)<br />
<br />
== Removal of website link ==<br />
<br />
Refers to this: https://wiki.archlinux.org/index.php?title=PipeWire&diff=next&oldid=653701<br />
<br />
I don't understand why that has to be removed. The official website should be always worth a mention, even if it is somehow mentioned in the text already.<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:02, 28 February 2021 (UTC)<br />
<br />
:The "See also" section is for additional links, it is not intended as a collection of all links used on a page. Adding links which are clearly mentioned in the appropriate place only clutters the list. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:24, 28 February 2021 (UTC)<br />
<br />
:: There are just three links and only one of them is really useful, the others could maybe even be removed as they link to old blog posts.<br />
:: I can only repeat myself, that things don't always have to be made more complicated than necessary.<br />
:: The official website is a central point which links to many more useful ressources, so it's one link for much information.<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:34, 28 February 2021 (UTC)<br />
<br />
== Removal of bootia32.efi generation procedure from X205TA install page. ==<br />
<br />
Those [https://wiki.archlinux.org/index.php?title=ASUS_x205ta&diff=596239&oldid=562734 instructions] were really straightforward and useful, imho in comparison present ones require too much material to be confident with. I think it's (paradoxically) way easier to generate the file than to configure a `grub.cfg` from zero to boot a live cd. Can we undo the edit? Otherwise we could put them in a new page or section in the GRUB page and link to them maybe. [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 05:07, 4 March 2021 (UTC)<br />
<br />
:If there is something wrong with the information on the [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Booting_64-bit_kernel_on_32-bit_UEFI general page], it should be improved instead of describing the same procedure in a different way on a completely unrelated page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:16, 6 March 2021 (UTC)<br />
<br />
:: I didn't know we had that info in the UEFI article. I think it could be appropriate to insert the [https://en.wikipedia.org/wiki/Template:See_also#Examples See also] archwiki equivalent (which I couldn't find) for UEFI page on top of the aforementioned section, what do you think? [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 13:28, 7 March 2021 (UTC)<br />
<br />
:::Well, the removed section was previously flagged with "Duplicates [[Unified Extensible Firmware Interface#Booting 64-bit kernel on 32-bit UEFI]]"...<br />
:::Also the laptops pages are usually related to most of the general pages on this wiki, adding all of them would be pretty useless. Users should not expect to find everything on a single laptop page, they should always check if there is a general page for their topic with more details.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:58, 7 March 2021 (UTC)<br />
<br />
== Re: Show how to use systemd/Timers with wg-quick@.service ==<br />
<br />
I don't think using service is the appropriate when you want to start Wireguard at boot. For most people connecting to a VPN is not exactly part system startup.<br />
A timer should more appropriate.<br />
[[User:ENV25|ENV25]] ([[User talk:ENV25|talk]]) 10:03, 11 April 2021 (UTC)<br />
<br />
:I don't see how OnBootSec=1min is more appropriate than an automatically starting service. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:19, 11 April 2021 (UTC)<br />
<br />
== USB flash installation medium (BIOS bootable) ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=next&oldid=673926 revert]: "making the partition bootable is discussed below"<br />
Do you mean installing syslinux and `dd` the [gpt]mbr with "discussed below"? This was not enought for my setup (Sandisk Ultra 64GB, Dell XPS 9370) to make the partition BIOS bootable. It did work right after I checked "Legacy BIOS Bootable" checkbox using gnome-disks.<br />
<br />
{{Unsigned|13:42, 30 May 2021 (UTC)|Auipga}}<br />
<br />
:Yes, that's what I meant. If it does not work, it should be fixed rather than providing a duplicate instruction without a reason. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:16, 30 May 2021 (UTC)<br />
<br />
== Systemd-networkd systemd-networkd-wait-online.service discussion modifications ==<br />
<br />
I'm not sure why you're reverting my edits.<br />
<br />
You said: "''empty ExecStart is explained in Systemd#Examples''"<br />
<br />
Exactly: Systemd#Examples clearly states "''As another example, in order to replace the ExecStart directive for a unit that is '''not of type oneshot'''''"<br />
<br />
'''systemd-networkd-wait-online''' is a oneshot service. By having the superfluous empty ExecStart you're just confusing people.<br />
<br />
Regarding the file naming, yes the name is irrelevant, but it's generally helpful to non-expert users to stick to canonical naming conventions.<br />
<br />
Please make sure you're on solid ground before reverting edits; you're just discouraging people from engaging with the Wiki. Thanks. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 16:51, 9 June 2021 (UTC)<br />
<br />
:{{man|5|systemd.service}} says: "Unless Type= is oneshot, exactly one command must be given. When Type=oneshot is used, zero or more commands may be specified."<br />
:So when a service is not oneshot, users ''must'' clear ExecStart before adding a modified command in the drop-in file. If a service is oneshot, they ''may or may not'' clear ExecStart, since the service may have multiple ExecStart commands.<br />
:In case of systemd-networkd-wait-online, I don't see why you would want to run multiple instances with different options: one to wait for ''all'' links (which is the default command) and another one to wait for ''any'' link (which is the command in the drop-in example). So clearing ExecStart really makes sense for systemd-networkd-wait-online.<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:44, 9 June 2021 (UTC)<br />
<br />
== Pacman: Install missing dependencies ==<br />
<br />
Hi. [https://wiki.archlinux.org/index.php?title=Pacman&type=revision&diff=690774&oldid=690762 "Pacman" Revision as of 21:50, 4 August 2021 (undo)] - maybe at least put that into [[System_maintenance#Avoid_certain_pacman_commands]]?<br />
<br />
[[User:Galeksandrp|Galeksandrp]] ([[User talk:Galeksandrp|talk]])<br />
<br />
:[[System_maintenance#Avoid_certain_pacman_commands]] already mentions {{ic|-Rdd}}. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:12, 14 August 2021 (UTC)<br />
<br />
== DPMS: "\033[9;0]" ==<br />
<br />
Hi. It seems that you removed {{ic|echo -ne "\033[9;0]"}} from [[Display Power Management Signaling|DPMS]]<br />
<br />
https://wiki.archlinux.org/index.php?title=Display_Power_Management_Signaling&diff=629705&oldid=625073<br />
<br />
[https://www.denx.de/wiki/view/DULG/SwitchOffScreenSaverAndBlinkingCursor A DULG page] and [https://unix.stackexchange.com/a/23636 a U&L post] brought me here.<br />
<br />
May I ask (1) if this method is still working; and (2) where is this escape sequence documented? [not found in {{man|4|console_codes}}]<br />
<br />
Thanks.<br />
<br />
{{Unsigned|05:23, 15 August 2021 (UTC)|PXf}}<br />
<br />
:[[Display Power Management Signaling#DPMS interaction in a Linux console with setterm]] says that setterm works by writing escape codes to the terminal device. The first subsection shows how to reverse-engineer the escape codes. Note that the escape codes are an implementation detail that users should not be concerned with, their documentation is certainly not our job. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:40, 15 August 2021 (UTC)<br />
<br />
== Linux console/Keyboard configuration ==<br />
<br />
Hi, you recently reverted my edit https://wiki.archlinux.org/index.php?title=Linux_console/Keyboard_configuration&oldid=693887. The reason I made that edit, was that I used to put my custom keymap in {{ic|/usr/local/share/kbd/keymaps/personal}} per the previous version of the wiki page. But this doesn't work with ''sd-vconsole'', as it's include files don't get loaded. Your suggested workaround by adding all required files using [[mkinitcpio#BINARIES and FILES|mkinitcpio BINARIES and FILES]] is rather tedious, as all the include files need to be in there, added by hand. This is done automatically by ''sd-vconsole'' if the file was put in {{ic|/usr/share/kbd/keymaps/}}. The reason I made this edit is due to https://bugs.archlinux.org/task/71788. See Giancarlo Razzolini's comment. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:43, 2 September 2021 (UTC)<br />
<br />
:It's just one custom file under {{ic|/usr/local}} and one entry in {{ic|FILES}}. What is so tedious about it? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:37, 2 September 2021 (UTC)<br />
<br />
:: It's not just one file. All the dependencies need to be included too under {{ic|/usr/share/kbd/keymaps/}}. There are quite a few in my case, when I just include ''us.map'' to modify it slightly. See the ''sd-vconsole'' hook script. That script has a part where it finds all the dependencies of a keymap.<br />
<br />
:: * ''/usr/share/kbd/keymaps/i386/include/compose.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/euro1.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-keys-bare.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-with-alt-and-altgr.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/qwerty-layout.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/personal.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/us.map''<br />
:: * ''/usr/share/kbd/keymaps/include/compose.latin1''<br />
<br />
:: [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 12:01, 2 September 2021 (UTC)<br />
<br />
::: I moved this to the talk page so I remember it and others can discuss too. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:18, 4 September 2021 (UTC)<br />
<br />
::: Oh, I see. In that case I suggest we add a tip like this:<br />
::: {{Tip|If you use the {{ic|sd-vconsole}} [[mkinitcpio#Common hooks|mkinitcpio hook]] instead of {{ic|keymap}}, keymaps located under {{ic|/usr/local}} as well as their dependencies from {{ic|/usr/share/kbd/keymaps}} need to be manually specified in the {{ic|FILES}} array in {{ic|mkinitcpio.conf}}. On the other hand, custom files located in {{ic|/usr/share/kbd/keymaps}} will be added automatically when configured in {{ic|/etc/vconsole.conf}}.}}<br />
::: Because this is relevant only for people using the {{ic|sd-vconsole}} hook and otherwise it does not make sense to pollute {{ic|/usr/share/kbd/keymaps}} with custom files.<br />
::: — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:55, 5 September 2021 (UTC)<br />
<br />
== cow_* ==<br />
<br />
Hi Lahwaacz. About the [https://wiki.archlinux.org/index.php?title=Archiso&diff=next&oldid=692981 how/why issue] (there will be no more &lt;!-- --&gt;). What if, for once, that I want to install some large packages after booting archiso, and would not bother modifying packages.x86_64 and building again? [https://www.memesmonkey.com/topic/works+on+my+machine <s>''on my machine''</s>] Darren "Un1Gfn" "[[User:PXf|PXf]]" Ng ([[User talk:PXf|talk]]) 08:18, 12 October 2021 (UTC)<br />
<br />
:It is a subsection of "Tips and tricks", not "Troubleshooting", so it should start with a clear motivation saying ''why'' the tip is useful, rather than an error message that the user has no idea if they will face or not. If you have such description, feel free to rewrite the section. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 05:42, 13 October 2021 (UTC)<br />
<br />
::What about making it a subsection of "[[Archiso#Troubleshooting|Troubleshooting]]" and renaming it to {{ic|partition / too full}}? [[User:PXf|PXf]] ([[User talk:PXf|talk]]) 06:45, 13 October 2021 (UTC)<br />
<br />
:::It's better to motivate it as a tip/trick rather than solve the problem after it happens. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:48, 13 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
(Undo revision 699881 by Oliver (talk) - installing arch-install-scripts does not get the image to "the same footing" as the archiso, even installing something for the first time is not an excuse to violate Help:Style#Package management instructions)<br />
<br />
'the same footing' may be poor choice of wording maybe but it's also not false. You are in a SIMILAR place, not 'exactly identical to the dot' e.g. same footing<br />
<br />
but 'installing something for the first time' is NOT what is going on here really. If we quote the style guide:<br />
<br />
''every Arch user should know pacman's article by memory''<br />
<br />
<br />
The thing is, this is NOT an Arch user yet. They have no idea what's going on, how to do stuff and just want to get started and installed. You can't expect _new_ not-yet-a user, to figure out everything in a daunting installation; by being a smart-bum about it. Yes, the style guide is completely correct on all other points. But I would think that this is the exception, rather then the rule. Help your new users a little. Introduce them gentle with open arms. From a 'first UX kind of way, this is horrible to treat your potentially new users.<br />
<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 17:40, 26 October 2021 (UTC)<br />
<br />
:We use the same convention on the [[Installation guide]] itself. They should read the [[pacman]] page to learn how to install packages as soon as possible, so why not right when they use it for the first time? There is a gentle link to "[[install]]" before the package name, so the clueless user will follow the link and learn something. They will not learn anything by copy-pasting a quick one-liner. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:59, 26 October 2021 (UTC)<br />
<br />
Yes, you ARE right, however; this is the install guide (relatively speaking) Let them install the system first with a gentle nudge; THEN force them to learn stuff :p<br />
<br />
Again, I understand the policy and the reasoning behind it very much so; but it's those first few steps that are the hardest. It's birds vs humans I suppose; birds through their children out of their nests to teach them to fly (or die); Humans raise their children first. Is arch really the 'l337 fly or die, rtfm n00b' kind of distro?</div>Oliverhttps://wiki.archlinux.org/index.php?title=User:Oliver/New_Install_Guide&diff=700015User:Oliver/New Install Guide2021-10-26T17:52:26Z<p>Oliver: Rename /mnt to /target; /mnt has meaning in LFS, also, giving meaning to mountpoint improves readability</p>
<hr />
<div>{{Unsupported|26 October 2021}}<br />
[[bg:Installation guide]]<br />
[[cs:Installation guide]]<br />
[[de:Arch Install Scripts]]<br />
[[el:Installation guide]]<br />
[[es:Installation guide]]<br />
[[fa:راهنمای تازهکاران]]<br />
[[fi:Installation guide]]<br />
[[fr:Installation guide]]<br />
[[hu:Installation guide]]<br />
[[it:Installation guide]]<br />
[[ja:インストールガイド]]<br />
[[ko:Installation guide]]<br />
[[lt:Installation guide]]<br />
[[pl:Installation guide]]<br />
[[pt:Installation guide]]<br />
[[ru:Installation guide]]<br />
[[sv:Installation guide]]<br />
[[th:Installation guide]]<br />
[[tr:Installation guide]]<br />
[[uk:Installation guide]]<br />
[[zh-hans:Installation guide]]<br />
[[zh-hant:Installation guide]]<br />
This document is a guide for installing [[Arch Linux]] using the live system booted from an installation medium made from an official installation image. The installation medium provides accessibility features which are described on the page [[Install Arch Linux with accessibility options]]. For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation.[https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html] A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available.<br />
<br />
== Pre-installation ==<br />
<br />
=== Acquire an installation image ===<br />
<br />
Visit the [https://archlinux.org/download/ Download] page and, depending on how you want to boot, acquire the ISO file or a netboot image, and the respective [[GnuPG]] signature.<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 [https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html serve malicious images]. <br />
<br />
On a system with [[GnuPG]] installed, do this by downloading the ''PGP signature'' (under ''Checksums'' in the [https://archlinux.org/download/ Download] page) to the ISO directory, and [[GnuPG#Verify a signature|verifying]] it with: <br />
<br />
$ gpg --keyserver-options auto-key-retrieve --verify archlinux-''version''-x86_64.iso.sig<br />
<br />
Alternatively, from an existing Arch Linux installation run:<br />
<br />
$ pacman-key -v archlinux-''version''-x86_64.iso.sig<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://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 />
=== Prepare an installation medium ===<br />
<br />
The installation image can be supplied to the target machine via a [[USB flash installation medium|USB flash drive]], an [[Optical disc drive#Burning|optical disc]] or a network with [[PXE]]: follow the appropriate article to prepare yourself an installation medium from the chosen image.<br />
<br />
=== Boot the live environment ===<br />
<br />
{{Note|Arch Linux installation images do not support Secure Boot. You will need to [[Unified Extensible Firmware Interface/Secure Boot#Disabling Secure Boot|disable Secure Boot]] to boot the installation medium. If desired, [[Secure Boot]] can be set up after completing the installation.}}<br />
<br />
# Point the current boot device to the one which has the Arch Linux installation medium. Typically it is achieved by pressing a key during the [[Wikipedia:Power-on self test|POST]] phase, as indicated on the splash screen. Refer to your motherboard's manual for details.<br />
# When the installation medium's boot loader menu appears, select ''Arch Linux install medium'' and press {{ic|Enter}} to enter the installation environment. {{Tip|The installation image uses [[systemd-boot]] for booting in UEFI mode and [[syslinux]] for booting in BIOS mode. See [https://gitlab.archlinux.org/mkinitcpio/mkinitcpio-archiso/blob/master/docs/README.bootparams README.bootparams] for a list of [[Kernel parameters#Configuration|boot parameters]].}}<br />
# You will be logged in on the first [[Wikipedia:Virtual console|virtual console]] as the root user, and presented with a [[Zsh]] shell prompt.<br />
<br />
To switch to a different console—for example, to view this guide with [https://lynx.invisible-island.net/lynx_help/Lynx_users_guide.html Lynx] alongside the installation—use the {{ic|Alt+''arrow''}} [[Keyboard shortcuts|shortcut]]. To [[textedit|edit]] configuration files, {{man|1|mcedit}}, [[nano#Usage|nano]] and [[vim#Usage|vim]] are available. See [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64 packages.x86_64] for a list of the packages included in the installation medium.<br />
<br />
=== Set the console keyboard layout ===<br />
<br />
The default [[console keymap]] is [[Wikipedia:File:KB United States-NoAltGr.svg|US]]. Available layouts can be listed with:<br />
<br />
# ls /usr/share/kbd/keymaps/**/*.map.gz<br />
<br />
To modify the layout, append a corresponding file name to {{man|1|loadkeys}}, omitting path and file extension. For example, to set a [[Wikipedia:File:KB Germany.svg|German]] keyboard layout:<br />
<br />
# loadkeys de-latin1<br />
<br />
[[Console fonts]] are located in {{ic|/usr/share/kbd/consolefonts/}} and can likewise be set with {{man|8|setfont}}.<br />
<br />
=== Verify the boot mode ===<br />
<br />
To verify the boot mode, list the [[efivars]] directory:<br />
<br />
# ls /sys/firmware/efi/efivars<br />
<br />
If the command shows the directory without error, then the system is booted in UEFI mode. If the directory does not exist, the system may be booted in [[Wikipedia:BIOS|BIOS]] (or [[Wikipedia:Compatibility Support Module|CSM]]) mode. If the system did not boot in the mode you desired, refer to your motherboard's manual.<br />
<br />
=== Connect to the internet ===<br />
<br />
To set up a network connection in the live environment, go through the following steps:<br />
<br />
* Ensure your [[network interface]] is listed and enabled, for example with {{man|8|ip-link}}: {{bc|# ip link}}<br />
* For wireless and WWAN, make sure the card is not blocked with [[rfkill]].<br />
* Connect to the network:<br />
** Ethernet—plug in the cable.<br />
** Wi-Fi—authenticate to the wireless network using [[iwctl]].<br />
** Mobile broadband modem—connect to the mobile network with the [[mmcli]] utility.<br />
* Configure your network connection:<br />
** [[DHCP]]: dynamic IP address and DNS server assignment (provided by [[systemd-networkd]] and [[systemd-resolved]]) should work out of the box for [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-ethernet.network Ethernet], [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wlan.network WLAN] and [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wwan.network WWAN] network interfaces.<br />
** Static IP address: follow [[Network configuration#Static IP address]].<br />
* The connection may be verified with [[Wikipedia:ping (networking utility)|ping]]: {{bc|# ping archlinux.org}}<br />
<br />
{{Note|In the installation image, [[systemd-networkd]], [[systemd-resolved]], [[iwd]] and [[ModemManager]] are preconfigured and enabled by default. That will not be the case for the installed system.}}<br />
<br />
=== Update the system clock ===<br />
<br />
Use {{man|1|timedatectl}} to ensure the system clock is accurate:<br />
<br />
# timedatectl set-ntp true<br />
<br />
To check the service status, use {{ic|timedatectl status}}.<br />
<br />
=== Partition the disks ===<br />
<br />
When recognized by the live system, disks are assigned to a [[block device]] such as {{ic|/dev/sda}}, {{ic|/dev/nvme0n1}} or {{ic|/dev/mmcblk0}}. To identify these devices, use [[lsblk]] or ''fdisk''.<br />
<br />
# fdisk -l<br />
<br />
Results ending in {{ic|rom}}, {{ic|loop}} or {{ic|airoot}} may be ignored.<br />
<br />
The following [[partition]]s are '''required''' for a chosen device:<br />
<br />
* One partition for the [[Wikipedia:Root directory|root directory]] {{ic|/}}.<br />
* For booting in [[UEFI]] mode: an [[EFI system partition]].<br />
<br />
If you want to create any stacked block devices for [[LVM]], [[dm-crypt|system encryption]] or [[RAID]], do it now.<br />
<br />
Use [[fdisk]] or [[parted]] to modify partition tables. For example:<br />
<br />
# fdisk ''/dev/the_disk_to_be_partitioned''<br />
<br />
{{Note|<br />
* [[Swap]] space can be set on a [[swap file]] for file systems supporting it.<br />
* If the disk from which you want to boot [[EFI system partition#Check for an existing partition|already has an EFI system partition]], do not create another one, but use the existing partition instead.<br />
}}<br />
<br />
==== Example layouts ====<br />
<br />
{| class="wikitable"<br />
|+ BIOS with [[MBR]]<br />
|-<br />
! Mount point<br />
! Partition<br />
! [[Wikipedia:Partition type|Partition type]]<br />
! Suggested size<br />
|-<br />
| {{ic|[SWAP]}}<br />
| {{ic|/dev/''swap_partition''}}<br />
| Linux swap<br />
| More than 512 MiB<br />
|-<br />
| {{ic|/target}}<br />
| {{ic|/dev/''root_partition''}}<br />
| Linux<br />
| Remainder of the device<br />
|}<br />
<br />
{| class="wikitable"<br />
|+ UEFI with [[GPT]]<br />
|-<br />
! Mount point<br />
! Partition<br />
! [[Wikipedia:GUID Partition Table#Partition type GUIDs|Partition type]]<br />
! Suggested size<br />
|-<br />
| {{ic|/target/boot}} or {{ic|/target/efi}}<sup>1</sup><br />
| {{ic|/dev/''efi_system_partition''}}<br />
| [[EFI system partition]]<br />
| At least 260 MiB<br />
|-<br />
| {{ic|[SWAP]}}<br />
| {{ic|/dev/''swap_partition''}}<br />
| Linux swap<br />
| More than 512 MiB<br />
|-<br />
| {{ic|/target}}<br />
| {{ic|/dev/''root_partition''}}<br />
| Linux x86-64 root (/)<br />
| Remainder of the device<br />
|}<br />
<br />
# {{ic|/target/efi}} should only be considered if the used boot loader is capable of loading the kernel and initramfs images from the root volume. See the warning in [[Arch boot process#Boot loader]].<br />
<br />
See also [[Partitioning#Example layouts]].<br />
<br />
=== Format the partitions ===<br />
<br />
Once the partitions have been created, each newly created partition must be formatted with an appropriate [[file system]]. For example, to create an Ext4 file system on {{ic|/dev/''root_partition''}}, run:<br />
<br />
# mkfs.ext4 /dev/''root_partition''<br />
<br />
If you created a partition for [[swap]], initialize it with {{man|8|mkswap}}:<br />
<br />
# mkswap /dev/''swap_partition''<br />
<br />
See [[File systems#Create a file system]] for details.<br />
<br />
{{Note|For stacked block devices replace {{ic|/dev/''*_partition''}} with the appropriate block device path.}}<br />
<br />
=== Mount the file systems ===<br />
<br />
[[Mount]] the root volume to {{ic|/target}}. For example, if the root volume is {{ic|/dev/''root_partition''}}:<br />
<br />
# mdkir -p /target<br />
# mount /dev/''root_partition'' /target<br />
<br />
Create any remaining mount points (such as {{ic|/target/efi}}) using {{man|1|mkdir}} and mount their corresponding volumes. <br />
<br />
If you created a [[swap]] volume, enable it with {{man|8|swapon}}:<br />
<br />
# swapon /dev/''swap_partition''<br />
<br />
{{man|8|genfstab}} will later detect mounted file systems and swap space.<br />
<br />
== Installation ==<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. On the live system, after connecting to the internet, [[reflector]] updates the mirror list by choosing 20 most recently synchronized HTTPS mirrors and sorting them by download rate.[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/xdg/reflector/reflector.conf]<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. You may want to inspect the file to see if it is satisfactory. If it is not, [[textedit|edit]] the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
Use the {{man|8|pacstrap}} script to install the {{Pkg|base}} package, Linux [[kernel]] and firmware for common hardware:<br />
<br />
# pacstrap /target base linux linux-firmware<br />
<br />
{{Tip|<br />
* You can substitute {{Pkg|linux}} for a [[kernel]] package of your choice, or you could omit it entirely when installing in a [[Wikipedia:Container (virtualization)|container]].<br />
* You could omit the installation of the firmware package when installing in a virtual machine or container.<br />
}}<br />
<br />
The {{Pkg|base}} package does not include all tools from the live installation, so installing other packages may be necessary for a fully functional base system. In particular, consider installing:<br />
<br />
* userspace utilities for the management of [[file systems]] that will be used on the system,<br />
* utilities for accessing [[RAID]] or [[LVM]] partitions,<br />
* specific firmware for other devices not included in {{Pkg|linux-firmware}} (e.g. {{Pkg|sof-firmware}} for [[Advanced Linux Sound Architecture#ALSA firmware|sound cards]]),<br />
* software necessary for [[networking]],<br />
* a [[text editor]],<br />
* packages for accessing documentation in [[man]] and [[info]] pages: {{Pkg|man-db}}, {{Pkg|man-pages}} and {{Pkg|texinfo}}.<br />
<br />
To [[install]] other packages or package groups, append the names to the ''pacstrap'' command above (space separated) or use [[pacman]] while [[#Chroot|chrooted into the new system]]. For comparison, packages available in the live system can be found in [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64 packages.x86_64].<br />
<br />
== Configure the system ==<br />
<br />
=== Fstab ===<br />
<br />
Generate an [[fstab]] file (use {{ic|-U}} or {{ic|-L}} to define by [[UUID]] or labels, respectively):<br />
<br />
# genfstab -U /target >> /target/etc/fstab<br />
<br />
Check the resulting {{ic|/target/etc/fstab}} file, and [[textedit|edit]] it in case of errors.<br />
<br />
=== Chroot ===<br />
<br />
[[Change root]] into the new system:<br />
<br />
# arch-chroot /target<br />
<br />
=== Time zone ===<br />
<br />
Set the [[time zone]]:<br />
<br />
# ln -sf /usr/share/zoneinfo/''Region''/''City'' /etc/localtime<br />
<br />
Run {{man|8|hwclock}} to generate {{ic|/etc/adjtime}}:<br />
<br />
# hwclock --systohc<br />
<br />
This command assumes the hardware clock is set to [[Wikipedia:UTC|UTC]]. See [[System time#Time standard]] for details.<br />
<br />
=== Localization ===<br />
<br />
[[textedit|Edit]] {{ic|/etc/locale.gen}} and uncomment {{ic|en_US.UTF-8 UTF-8}} and other needed [[locale]]s. Generate the locales by running:<br />
<br />
# locale-gen<br />
<br />
[[Create]] the {{man|5|locale.conf}} file, and [[Locale#Setting the system locale|set the LANG variable]] accordingly:<br />
<br />
{{hc|1=/etc/locale.conf|2=<br />
LANG=''en_US.UTF-8''<br />
}}<br />
<br />
If you [[#Set the console keyboard layout|set the console keyboard layout]], make the changes persistent in {{man|5|vconsole.conf}}:<br />
<br />
{{hc|1=/etc/vconsole.conf|2=<br />
KEYMAP=''de-latin1''<br />
}}<br />
<br />
=== Network configuration ===<br />
<br />
[[Create]] the [[hostname]] file:<br />
<br />
{{hc|/etc/hostname|<br />
''myhostname''<br />
}}<br />
<br />
Complete the [[network configuration]] for the newly installed environment. That may include installing suitable [[network management]] software.<br />
<br />
=== Initramfs ===<br />
<br />
Creating a new ''initramfs'' is usually not required, because [[mkinitcpio]] was run on installation of the [[kernel]] package with ''pacstrap''.<br />
<br />
For [[Install Arch Linux on LVM#Adding mkinitcpio hooks|LVM]], [[dm-crypt|system encryption]] or [[RAID#Configure mkinitcpio|RAID]], modify {{man|5|mkinitcpio.conf}} and recreate the initramfs image:<br />
<br />
# mkinitcpio -P<br />
<br />
=== Root password ===<br />
<br />
Set the root [[password]]:<br />
<br />
# passwd<br />
<br />
=== Boot loader ===<br />
<br />
Choose and install a Linux-capable [[boot loader]]. If you have an Intel or AMD CPU, enable [[microcode]] updates in addition.<br />
<br />
== Reboot ==<br />
<br />
Exit the chroot environment by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R /target}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
Finally, restart the machine by typing {{ic|reboot}}: any partitions still mounted will be automatically unmounted by ''systemd''. Remember to remove the installation medium and then login into the new system with the root account.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like creating unprivileged user accounts, setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=User:Oliver/New_Install_Guide&diff=700014User:Oliver/New Install Guide2021-10-26T17:50:10Z<p>Oliver: Mark as 'draft'</p>
<hr />
<div>{{Unsupported|26 October 2021}}<br />
[[bg:Installation guide]]<br />
[[cs:Installation guide]]<br />
[[de:Arch Install Scripts]]<br />
[[el:Installation guide]]<br />
[[es:Installation guide]]<br />
[[fa:راهنمای تازهکاران]]<br />
[[fi:Installation guide]]<br />
[[fr:Installation guide]]<br />
[[hu:Installation guide]]<br />
[[it:Installation guide]]<br />
[[ja:インストールガイド]]<br />
[[ko:Installation guide]]<br />
[[lt:Installation guide]]<br />
[[pl:Installation guide]]<br />
[[pt:Installation guide]]<br />
[[ru:Installation guide]]<br />
[[sv:Installation guide]]<br />
[[th:Installation guide]]<br />
[[tr:Installation guide]]<br />
[[uk:Installation guide]]<br />
[[zh-hans:Installation guide]]<br />
[[zh-hant:Installation guide]]<br />
This document is a guide for installing [[Arch Linux]] using the live system booted from an installation medium made from an official installation image. The installation medium provides accessibility features which are described on the page [[Install Arch Linux with accessibility options]]. For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation.[https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html] A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available.<br />
<br />
== Pre-installation ==<br />
<br />
=== Acquire an installation image ===<br />
<br />
Visit the [https://archlinux.org/download/ Download] page and, depending on how you want to boot, acquire the ISO file or a netboot image, and the respective [[GnuPG]] signature.<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 [https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html serve malicious images]. <br />
<br />
On a system with [[GnuPG]] installed, do this by downloading the ''PGP signature'' (under ''Checksums'' in the [https://archlinux.org/download/ Download] page) to the ISO directory, and [[GnuPG#Verify a signature|verifying]] it with: <br />
<br />
$ gpg --keyserver-options auto-key-retrieve --verify archlinux-''version''-x86_64.iso.sig<br />
<br />
Alternatively, from an existing Arch Linux installation run:<br />
<br />
$ pacman-key -v archlinux-''version''-x86_64.iso.sig<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://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 />
=== Prepare an installation medium ===<br />
<br />
The installation image can be supplied to the target machine via a [[USB flash installation medium|USB flash drive]], an [[Optical disc drive#Burning|optical disc]] or a network with [[PXE]]: follow the appropriate article to prepare yourself an installation medium from the chosen image.<br />
<br />
=== Boot the live environment ===<br />
<br />
{{Note|Arch Linux installation images do not support Secure Boot. You will need to [[Unified Extensible Firmware Interface/Secure Boot#Disabling Secure Boot|disable Secure Boot]] to boot the installation medium. If desired, [[Secure Boot]] can be set up after completing the installation.}}<br />
<br />
# Point the current boot device to the one which has the Arch Linux installation medium. Typically it is achieved by pressing a key during the [[Wikipedia:Power-on self test|POST]] phase, as indicated on the splash screen. Refer to your motherboard's manual for details.<br />
# When the installation medium's boot loader menu appears, select ''Arch Linux install medium'' and press {{ic|Enter}} to enter the installation environment. {{Tip|The installation image uses [[systemd-boot]] for booting in UEFI mode and [[syslinux]] for booting in BIOS mode. See [https://gitlab.archlinux.org/mkinitcpio/mkinitcpio-archiso/blob/master/docs/README.bootparams README.bootparams] for a list of [[Kernel parameters#Configuration|boot parameters]].}}<br />
# You will be logged in on the first [[Wikipedia:Virtual console|virtual console]] as the root user, and presented with a [[Zsh]] shell prompt.<br />
<br />
To switch to a different console—for example, to view this guide with [https://lynx.invisible-island.net/lynx_help/Lynx_users_guide.html Lynx] alongside the installation—use the {{ic|Alt+''arrow''}} [[Keyboard shortcuts|shortcut]]. To [[textedit|edit]] configuration files, {{man|1|mcedit}}, [[nano#Usage|nano]] and [[vim#Usage|vim]] are available. See [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64 packages.x86_64] for a list of the packages included in the installation medium.<br />
<br />
=== Set the console keyboard layout ===<br />
<br />
The default [[console keymap]] is [[Wikipedia:File:KB United States-NoAltGr.svg|US]]. Available layouts can be listed with:<br />
<br />
# ls /usr/share/kbd/keymaps/**/*.map.gz<br />
<br />
To modify the layout, append a corresponding file name to {{man|1|loadkeys}}, omitting path and file extension. For example, to set a [[Wikipedia:File:KB Germany.svg|German]] keyboard layout:<br />
<br />
# loadkeys de-latin1<br />
<br />
[[Console fonts]] are located in {{ic|/usr/share/kbd/consolefonts/}} and can likewise be set with {{man|8|setfont}}.<br />
<br />
=== Verify the boot mode ===<br />
<br />
To verify the boot mode, list the [[efivars]] directory:<br />
<br />
# ls /sys/firmware/efi/efivars<br />
<br />
If the command shows the directory without error, then the system is booted in UEFI mode. If the directory does not exist, the system may be booted in [[Wikipedia:BIOS|BIOS]] (or [[Wikipedia:Compatibility Support Module|CSM]]) mode. If the system did not boot in the mode you desired, refer to your motherboard's manual.<br />
<br />
=== Connect to the internet ===<br />
<br />
To set up a network connection in the live environment, go through the following steps:<br />
<br />
* Ensure your [[network interface]] is listed and enabled, for example with {{man|8|ip-link}}: {{bc|# ip link}}<br />
* For wireless and WWAN, make sure the card is not blocked with [[rfkill]].<br />
* Connect to the network:<br />
** Ethernet—plug in the cable.<br />
** Wi-Fi—authenticate to the wireless network using [[iwctl]].<br />
** Mobile broadband modem—connect to the mobile network with the [[mmcli]] utility.<br />
* Configure your network connection:<br />
** [[DHCP]]: dynamic IP address and DNS server assignment (provided by [[systemd-networkd]] and [[systemd-resolved]]) should work out of the box for [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-ethernet.network Ethernet], [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wlan.network WLAN] and [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wwan.network WWAN] network interfaces.<br />
** Static IP address: follow [[Network configuration#Static IP address]].<br />
* The connection may be verified with [[Wikipedia:ping (networking utility)|ping]]: {{bc|# ping archlinux.org}}<br />
<br />
{{Note|In the installation image, [[systemd-networkd]], [[systemd-resolved]], [[iwd]] and [[ModemManager]] are preconfigured and enabled by default. That will not be the case for the installed system.}}<br />
<br />
=== Update the system clock ===<br />
<br />
Use {{man|1|timedatectl}} to ensure the system clock is accurate:<br />
<br />
# timedatectl set-ntp true<br />
<br />
To check the service status, use {{ic|timedatectl status}}.<br />
<br />
=== Partition the disks ===<br />
<br />
When recognized by the live system, disks are assigned to a [[block device]] such as {{ic|/dev/sda}}, {{ic|/dev/nvme0n1}} or {{ic|/dev/mmcblk0}}. To identify these devices, use [[lsblk]] or ''fdisk''.<br />
<br />
# fdisk -l<br />
<br />
Results ending in {{ic|rom}}, {{ic|loop}} or {{ic|airoot}} may be ignored.<br />
<br />
The following [[partition]]s are '''required''' for a chosen device:<br />
<br />
* One partition for the [[Wikipedia:Root directory|root directory]] {{ic|/}}.<br />
* For booting in [[UEFI]] mode: an [[EFI system partition]].<br />
<br />
If you want to create any stacked block devices for [[LVM]], [[dm-crypt|system encryption]] or [[RAID]], do it now.<br />
<br />
Use [[fdisk]] or [[parted]] to modify partition tables. For example:<br />
<br />
# fdisk ''/dev/the_disk_to_be_partitioned''<br />
<br />
{{Note|<br />
* [[Swap]] space can be set on a [[swap file]] for file systems supporting it.<br />
* If the disk from which you want to boot [[EFI system partition#Check for an existing partition|already has an EFI system partition]], do not create another one, but use the existing partition instead.<br />
}}<br />
<br />
==== Example layouts ====<br />
<br />
{| class="wikitable"<br />
|+ BIOS with [[MBR]]<br />
|-<br />
! Mount point<br />
! Partition<br />
! [[Wikipedia:Partition type|Partition type]]<br />
! Suggested size<br />
|-<br />
| {{ic|[SWAP]}}<br />
| {{ic|/dev/''swap_partition''}}<br />
| Linux swap<br />
| More than 512 MiB<br />
|-<br />
| {{ic|/mnt}}<br />
| {{ic|/dev/''root_partition''}}<br />
| Linux<br />
| Remainder of the device<br />
|}<br />
<br />
{| class="wikitable"<br />
|+ UEFI with [[GPT]]<br />
|-<br />
! Mount point<br />
! Partition<br />
! [[Wikipedia:GUID Partition Table#Partition type GUIDs|Partition type]]<br />
! Suggested size<br />
|-<br />
| {{ic|/mnt/boot}} or {{ic|/mnt/efi}}<sup>1</sup><br />
| {{ic|/dev/''efi_system_partition''}}<br />
| [[EFI system partition]]<br />
| At least 260 MiB<br />
|-<br />
| {{ic|[SWAP]}}<br />
| {{ic|/dev/''swap_partition''}}<br />
| Linux swap<br />
| More than 512 MiB<br />
|-<br />
| {{ic|/mnt}}<br />
| {{ic|/dev/''root_partition''}}<br />
| Linux x86-64 root (/)<br />
| Remainder of the device<br />
|}<br />
<br />
# {{ic|/mnt/efi}} should only be considered if the used boot loader is capable of loading the kernel and initramfs images from the root volume. See the warning in [[Arch boot process#Boot loader]].<br />
<br />
See also [[Partitioning#Example layouts]].<br />
<br />
=== Format the partitions ===<br />
<br />
Once the partitions have been created, each newly created partition must be formatted with an appropriate [[file system]]. For example, to create an Ext4 file system on {{ic|/dev/''root_partition''}}, run:<br />
<br />
# mkfs.ext4 /dev/''root_partition''<br />
<br />
If you created a partition for [[swap]], initialize it with {{man|8|mkswap}}:<br />
<br />
# mkswap /dev/''swap_partition''<br />
<br />
See [[File systems#Create a file system]] for details.<br />
<br />
{{Note|For stacked block devices replace {{ic|/dev/''*_partition''}} with the appropriate block device path.}}<br />
<br />
=== Mount the file systems ===<br />
<br />
[[Mount]] the root volume to {{ic|/mnt}}. For example, if the root volume is {{ic|/dev/''root_partition''}}:<br />
<br />
# mount /dev/''root_partition'' /mnt<br />
<br />
Create any remaining mount points (such as {{ic|/mnt/efi}}) using {{man|1|mkdir}} and mount their corresponding volumes. <br />
<br />
If you created a [[swap]] volume, enable it with {{man|8|swapon}}:<br />
<br />
# swapon /dev/''swap_partition''<br />
<br />
{{man|8|genfstab}} will later detect mounted file systems and swap space.<br />
<br />
== Installation ==<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. On the live system, after connecting to the internet, [[reflector]] updates the mirror list by choosing 20 most recently synchronized HTTPS mirrors and sorting them by download rate.[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/xdg/reflector/reflector.conf]<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. You may want to inspect the file to see if it is satisfactory. If it is not, [[textedit|edit]] the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
Use the {{man|8|pacstrap}} script to install the {{Pkg|base}} package, Linux [[kernel]] and firmware for common hardware:<br />
<br />
# pacstrap /mnt base linux linux-firmware<br />
<br />
{{Tip|<br />
* You can substitute {{Pkg|linux}} for a [[kernel]] package of your choice, or you could omit it entirely when installing in a [[Wikipedia:Container (virtualization)|container]].<br />
* You could omit the installation of the firmware package when installing in a virtual machine or container.<br />
}}<br />
<br />
The {{Pkg|base}} package does not include all tools from the live installation, so installing other packages may be necessary for a fully functional base system. In particular, consider installing:<br />
<br />
* userspace utilities for the management of [[file systems]] that will be used on the system,<br />
* utilities for accessing [[RAID]] or [[LVM]] partitions,<br />
* specific firmware for other devices not included in {{Pkg|linux-firmware}} (e.g. {{Pkg|sof-firmware}} for [[Advanced Linux Sound Architecture#ALSA firmware|sound cards]]),<br />
* software necessary for [[networking]],<br />
* a [[text editor]],<br />
* packages for accessing documentation in [[man]] and [[info]] pages: {{Pkg|man-db}}, {{Pkg|man-pages}} and {{Pkg|texinfo}}.<br />
<br />
To [[install]] other packages or package groups, append the names to the ''pacstrap'' command above (space separated) or use [[pacman]] while [[#Chroot|chrooted into the new system]]. For comparison, packages available in the live system can be found in [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64 packages.x86_64].<br />
<br />
== Configure the system ==<br />
<br />
=== Fstab ===<br />
<br />
Generate an [[fstab]] file (use {{ic|-U}} or {{ic|-L}} to define by [[UUID]] or labels, respectively):<br />
<br />
# genfstab -U /mnt >> /mnt/etc/fstab<br />
<br />
Check the resulting {{ic|/mnt/etc/fstab}} file, and [[textedit|edit]] it in case of errors.<br />
<br />
=== Chroot ===<br />
<br />
[[Change root]] into the new system:<br />
<br />
# arch-chroot /mnt<br />
<br />
=== Time zone ===<br />
<br />
Set the [[time zone]]:<br />
<br />
# ln -sf /usr/share/zoneinfo/''Region''/''City'' /etc/localtime<br />
<br />
Run {{man|8|hwclock}} to generate {{ic|/etc/adjtime}}:<br />
<br />
# hwclock --systohc<br />
<br />
This command assumes the hardware clock is set to [[Wikipedia:UTC|UTC]]. See [[System time#Time standard]] for details.<br />
<br />
=== Localization ===<br />
<br />
[[textedit|Edit]] {{ic|/etc/locale.gen}} and uncomment {{ic|en_US.UTF-8 UTF-8}} and other needed [[locale]]s. Generate the locales by running:<br />
<br />
# locale-gen<br />
<br />
[[Create]] the {{man|5|locale.conf}} file, and [[Locale#Setting the system locale|set the LANG variable]] accordingly:<br />
<br />
{{hc|1=/etc/locale.conf|2=<br />
LANG=''en_US.UTF-8''<br />
}}<br />
<br />
If you [[#Set the console keyboard layout|set the console keyboard layout]], make the changes persistent in {{man|5|vconsole.conf}}:<br />
<br />
{{hc|1=/etc/vconsole.conf|2=<br />
KEYMAP=''de-latin1''<br />
}}<br />
<br />
=== Network configuration ===<br />
<br />
[[Create]] the [[hostname]] file:<br />
<br />
{{hc|/etc/hostname|<br />
''myhostname''<br />
}}<br />
<br />
Complete the [[network configuration]] for the newly installed environment. That may include installing suitable [[network management]] software.<br />
<br />
=== Initramfs ===<br />
<br />
Creating a new ''initramfs'' is usually not required, because [[mkinitcpio]] was run on installation of the [[kernel]] package with ''pacstrap''.<br />
<br />
For [[Install Arch Linux on LVM#Adding mkinitcpio hooks|LVM]], [[dm-crypt|system encryption]] or [[RAID#Configure mkinitcpio|RAID]], modify {{man|5|mkinitcpio.conf}} and recreate the initramfs image:<br />
<br />
# mkinitcpio -P<br />
<br />
=== Root password ===<br />
<br />
Set the root [[password]]:<br />
<br />
# passwd<br />
<br />
=== Boot loader ===<br />
<br />
Choose and install a Linux-capable [[boot loader]]. If you have an Intel or AMD CPU, enable [[microcode]] updates in addition.<br />
<br />
== Reboot ==<br />
<br />
Exit the chroot environment by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R /mnt}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
Finally, restart the machine by typing {{ic|reboot}}: any partitions still mounted will be automatically unmounted by ''systemd''. Remember to remove the installation medium and then login into the new system with the root account.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like creating unprivileged user accounts, setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=User:Oliver/New_Install_Guide&diff=700013User:Oliver/New Install Guide2021-10-26T17:49:43Z<p>Oliver: Initial import</p>
<hr />
<div>[[Category:Installation process]]<br />
[[bg:Installation guide]]<br />
[[cs:Installation guide]]<br />
[[de:Arch Install Scripts]]<br />
[[el:Installation guide]]<br />
[[es:Installation guide]]<br />
[[fa:راهنمای تازهکاران]]<br />
[[fi:Installation guide]]<br />
[[fr:Installation guide]]<br />
[[hu:Installation guide]]<br />
[[it:Installation guide]]<br />
[[ja:インストールガイド]]<br />
[[ko:Installation guide]]<br />
[[lt:Installation guide]]<br />
[[pl:Installation guide]]<br />
[[pt:Installation guide]]<br />
[[ru:Installation guide]]<br />
[[sv:Installation guide]]<br />
[[th:Installation guide]]<br />
[[tr:Installation guide]]<br />
[[uk:Installation guide]]<br />
[[zh-hans:Installation guide]]<br />
[[zh-hant:Installation guide]]<br />
This document is a guide for installing [[Arch Linux]] using the live system booted from an installation medium made from an official installation image. The installation medium provides accessibility features which are described on the page [[Install Arch Linux with accessibility options]]. For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation.[https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html] A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available.<br />
<br />
== Pre-installation ==<br />
<br />
=== Acquire an installation image ===<br />
<br />
Visit the [https://archlinux.org/download/ Download] page and, depending on how you want to boot, acquire the ISO file or a netboot image, and the respective [[GnuPG]] signature.<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 [https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html serve malicious images]. <br />
<br />
On a system with [[GnuPG]] installed, do this by downloading the ''PGP signature'' (under ''Checksums'' in the [https://archlinux.org/download/ Download] page) to the ISO directory, and [[GnuPG#Verify a signature|verifying]] it with: <br />
<br />
$ gpg --keyserver-options auto-key-retrieve --verify archlinux-''version''-x86_64.iso.sig<br />
<br />
Alternatively, from an existing Arch Linux installation run:<br />
<br />
$ pacman-key -v archlinux-''version''-x86_64.iso.sig<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://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 />
=== Prepare an installation medium ===<br />
<br />
The installation image can be supplied to the target machine via a [[USB flash installation medium|USB flash drive]], an [[Optical disc drive#Burning|optical disc]] or a network with [[PXE]]: follow the appropriate article to prepare yourself an installation medium from the chosen image.<br />
<br />
=== Boot the live environment ===<br />
<br />
{{Note|Arch Linux installation images do not support Secure Boot. You will need to [[Unified Extensible Firmware Interface/Secure Boot#Disabling Secure Boot|disable Secure Boot]] to boot the installation medium. If desired, [[Secure Boot]] can be set up after completing the installation.}}<br />
<br />
# Point the current boot device to the one which has the Arch Linux installation medium. Typically it is achieved by pressing a key during the [[Wikipedia:Power-on self test|POST]] phase, as indicated on the splash screen. Refer to your motherboard's manual for details.<br />
# When the installation medium's boot loader menu appears, select ''Arch Linux install medium'' and press {{ic|Enter}} to enter the installation environment. {{Tip|The installation image uses [[systemd-boot]] for booting in UEFI mode and [[syslinux]] for booting in BIOS mode. See [https://gitlab.archlinux.org/mkinitcpio/mkinitcpio-archiso/blob/master/docs/README.bootparams README.bootparams] for a list of [[Kernel parameters#Configuration|boot parameters]].}}<br />
# You will be logged in on the first [[Wikipedia:Virtual console|virtual console]] as the root user, and presented with a [[Zsh]] shell prompt.<br />
<br />
To switch to a different console—for example, to view this guide with [https://lynx.invisible-island.net/lynx_help/Lynx_users_guide.html Lynx] alongside the installation—use the {{ic|Alt+''arrow''}} [[Keyboard shortcuts|shortcut]]. To [[textedit|edit]] configuration files, {{man|1|mcedit}}, [[nano#Usage|nano]] and [[vim#Usage|vim]] are available. See [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64 packages.x86_64] for a list of the packages included in the installation medium.<br />
<br />
=== Set the console keyboard layout ===<br />
<br />
The default [[console keymap]] is [[Wikipedia:File:KB United States-NoAltGr.svg|US]]. Available layouts can be listed with:<br />
<br />
# ls /usr/share/kbd/keymaps/**/*.map.gz<br />
<br />
To modify the layout, append a corresponding file name to {{man|1|loadkeys}}, omitting path and file extension. For example, to set a [[Wikipedia:File:KB Germany.svg|German]] keyboard layout:<br />
<br />
# loadkeys de-latin1<br />
<br />
[[Console fonts]] are located in {{ic|/usr/share/kbd/consolefonts/}} and can likewise be set with {{man|8|setfont}}.<br />
<br />
=== Verify the boot mode ===<br />
<br />
To verify the boot mode, list the [[efivars]] directory:<br />
<br />
# ls /sys/firmware/efi/efivars<br />
<br />
If the command shows the directory without error, then the system is booted in UEFI mode. If the directory does not exist, the system may be booted in [[Wikipedia:BIOS|BIOS]] (or [[Wikipedia:Compatibility Support Module|CSM]]) mode. If the system did not boot in the mode you desired, refer to your motherboard's manual.<br />
<br />
=== Connect to the internet ===<br />
<br />
To set up a network connection in the live environment, go through the following steps:<br />
<br />
* Ensure your [[network interface]] is listed and enabled, for example with {{man|8|ip-link}}: {{bc|# ip link}}<br />
* For wireless and WWAN, make sure the card is not blocked with [[rfkill]].<br />
* Connect to the network:<br />
** Ethernet—plug in the cable.<br />
** Wi-Fi—authenticate to the wireless network using [[iwctl]].<br />
** Mobile broadband modem—connect to the mobile network with the [[mmcli]] utility.<br />
* Configure your network connection:<br />
** [[DHCP]]: dynamic IP address and DNS server assignment (provided by [[systemd-networkd]] and [[systemd-resolved]]) should work out of the box for [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-ethernet.network Ethernet], [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wlan.network WLAN] and [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/network/20-wwan.network WWAN] network interfaces.<br />
** Static IP address: follow [[Network configuration#Static IP address]].<br />
* The connection may be verified with [[Wikipedia:ping (networking utility)|ping]]: {{bc|# ping archlinux.org}}<br />
<br />
{{Note|In the installation image, [[systemd-networkd]], [[systemd-resolved]], [[iwd]] and [[ModemManager]] are preconfigured and enabled by default. That will not be the case for the installed system.}}<br />
<br />
=== Update the system clock ===<br />
<br />
Use {{man|1|timedatectl}} to ensure the system clock is accurate:<br />
<br />
# timedatectl set-ntp true<br />
<br />
To check the service status, use {{ic|timedatectl status}}.<br />
<br />
=== Partition the disks ===<br />
<br />
When recognized by the live system, disks are assigned to a [[block device]] such as {{ic|/dev/sda}}, {{ic|/dev/nvme0n1}} or {{ic|/dev/mmcblk0}}. To identify these devices, use [[lsblk]] or ''fdisk''.<br />
<br />
# fdisk -l<br />
<br />
Results ending in {{ic|rom}}, {{ic|loop}} or {{ic|airoot}} may be ignored.<br />
<br />
The following [[partition]]s are '''required''' for a chosen device:<br />
<br />
* One partition for the [[Wikipedia:Root directory|root directory]] {{ic|/}}.<br />
* For booting in [[UEFI]] mode: an [[EFI system partition]].<br />
<br />
If you want to create any stacked block devices for [[LVM]], [[dm-crypt|system encryption]] or [[RAID]], do it now.<br />
<br />
Use [[fdisk]] or [[parted]] to modify partition tables. For example:<br />
<br />
# fdisk ''/dev/the_disk_to_be_partitioned''<br />
<br />
{{Note|<br />
* [[Swap]] space can be set on a [[swap file]] for file systems supporting it.<br />
* If the disk from which you want to boot [[EFI system partition#Check for an existing partition|already has an EFI system partition]], do not create another one, but use the existing partition instead.<br />
}}<br />
<br />
==== Example layouts ====<br />
<br />
{| class="wikitable"<br />
|+ BIOS with [[MBR]]<br />
|-<br />
! Mount point<br />
! Partition<br />
! [[Wikipedia:Partition type|Partition type]]<br />
! Suggested size<br />
|-<br />
| {{ic|[SWAP]}}<br />
| {{ic|/dev/''swap_partition''}}<br />
| Linux swap<br />
| More than 512 MiB<br />
|-<br />
| {{ic|/mnt}}<br />
| {{ic|/dev/''root_partition''}}<br />
| Linux<br />
| Remainder of the device<br />
|}<br />
<br />
{| class="wikitable"<br />
|+ UEFI with [[GPT]]<br />
|-<br />
! Mount point<br />
! Partition<br />
! [[Wikipedia:GUID Partition Table#Partition type GUIDs|Partition type]]<br />
! Suggested size<br />
|-<br />
| {{ic|/mnt/boot}} or {{ic|/mnt/efi}}<sup>1</sup><br />
| {{ic|/dev/''efi_system_partition''}}<br />
| [[EFI system partition]]<br />
| At least 260 MiB<br />
|-<br />
| {{ic|[SWAP]}}<br />
| {{ic|/dev/''swap_partition''}}<br />
| Linux swap<br />
| More than 512 MiB<br />
|-<br />
| {{ic|/mnt}}<br />
| {{ic|/dev/''root_partition''}}<br />
| Linux x86-64 root (/)<br />
| Remainder of the device<br />
|}<br />
<br />
# {{ic|/mnt/efi}} should only be considered if the used boot loader is capable of loading the kernel and initramfs images from the root volume. See the warning in [[Arch boot process#Boot loader]].<br />
<br />
See also [[Partitioning#Example layouts]].<br />
<br />
=== Format the partitions ===<br />
<br />
Once the partitions have been created, each newly created partition must be formatted with an appropriate [[file system]]. For example, to create an Ext4 file system on {{ic|/dev/''root_partition''}}, run:<br />
<br />
# mkfs.ext4 /dev/''root_partition''<br />
<br />
If you created a partition for [[swap]], initialize it with {{man|8|mkswap}}:<br />
<br />
# mkswap /dev/''swap_partition''<br />
<br />
See [[File systems#Create a file system]] for details.<br />
<br />
{{Note|For stacked block devices replace {{ic|/dev/''*_partition''}} with the appropriate block device path.}}<br />
<br />
=== Mount the file systems ===<br />
<br />
[[Mount]] the root volume to {{ic|/mnt}}. For example, if the root volume is {{ic|/dev/''root_partition''}}:<br />
<br />
# mount /dev/''root_partition'' /mnt<br />
<br />
Create any remaining mount points (such as {{ic|/mnt/efi}}) using {{man|1|mkdir}} and mount their corresponding volumes. <br />
<br />
If you created a [[swap]] volume, enable it with {{man|8|swapon}}:<br />
<br />
# swapon /dev/''swap_partition''<br />
<br />
{{man|8|genfstab}} will later detect mounted file systems and swap space.<br />
<br />
== Installation ==<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. On the live system, after connecting to the internet, [[reflector]] updates the mirror list by choosing 20 most recently synchronized HTTPS mirrors and sorting them by download rate.[https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/xdg/reflector/reflector.conf]<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. You may want to inspect the file to see if it is satisfactory. If it is not, [[textedit|edit]] the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
Use the {{man|8|pacstrap}} script to install the {{Pkg|base}} package, Linux [[kernel]] and firmware for common hardware:<br />
<br />
# pacstrap /mnt base linux linux-firmware<br />
<br />
{{Tip|<br />
* You can substitute {{Pkg|linux}} for a [[kernel]] package of your choice, or you could omit it entirely when installing in a [[Wikipedia:Container (virtualization)|container]].<br />
* You could omit the installation of the firmware package when installing in a virtual machine or container.<br />
}}<br />
<br />
The {{Pkg|base}} package does not include all tools from the live installation, so installing other packages may be necessary for a fully functional base system. In particular, consider installing:<br />
<br />
* userspace utilities for the management of [[file systems]] that will be used on the system,<br />
* utilities for accessing [[RAID]] or [[LVM]] partitions,<br />
* specific firmware for other devices not included in {{Pkg|linux-firmware}} (e.g. {{Pkg|sof-firmware}} for [[Advanced Linux Sound Architecture#ALSA firmware|sound cards]]),<br />
* software necessary for [[networking]],<br />
* a [[text editor]],<br />
* packages for accessing documentation in [[man]] and [[info]] pages: {{Pkg|man-db}}, {{Pkg|man-pages}} and {{Pkg|texinfo}}.<br />
<br />
To [[install]] other packages or package groups, append the names to the ''pacstrap'' command above (space separated) or use [[pacman]] while [[#Chroot|chrooted into the new system]]. For comparison, packages available in the live system can be found in [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/packages.x86_64 packages.x86_64].<br />
<br />
== Configure the system ==<br />
<br />
=== Fstab ===<br />
<br />
Generate an [[fstab]] file (use {{ic|-U}} or {{ic|-L}} to define by [[UUID]] or labels, respectively):<br />
<br />
# genfstab -U /mnt >> /mnt/etc/fstab<br />
<br />
Check the resulting {{ic|/mnt/etc/fstab}} file, and [[textedit|edit]] it in case of errors.<br />
<br />
=== Chroot ===<br />
<br />
[[Change root]] into the new system:<br />
<br />
# arch-chroot /mnt<br />
<br />
=== Time zone ===<br />
<br />
Set the [[time zone]]:<br />
<br />
# ln -sf /usr/share/zoneinfo/''Region''/''City'' /etc/localtime<br />
<br />
Run {{man|8|hwclock}} to generate {{ic|/etc/adjtime}}:<br />
<br />
# hwclock --systohc<br />
<br />
This command assumes the hardware clock is set to [[Wikipedia:UTC|UTC]]. See [[System time#Time standard]] for details.<br />
<br />
=== Localization ===<br />
<br />
[[textedit|Edit]] {{ic|/etc/locale.gen}} and uncomment {{ic|en_US.UTF-8 UTF-8}} and other needed [[locale]]s. Generate the locales by running:<br />
<br />
# locale-gen<br />
<br />
[[Create]] the {{man|5|locale.conf}} file, and [[Locale#Setting the system locale|set the LANG variable]] accordingly:<br />
<br />
{{hc|1=/etc/locale.conf|2=<br />
LANG=''en_US.UTF-8''<br />
}}<br />
<br />
If you [[#Set the console keyboard layout|set the console keyboard layout]], make the changes persistent in {{man|5|vconsole.conf}}:<br />
<br />
{{hc|1=/etc/vconsole.conf|2=<br />
KEYMAP=''de-latin1''<br />
}}<br />
<br />
=== Network configuration ===<br />
<br />
[[Create]] the [[hostname]] file:<br />
<br />
{{hc|/etc/hostname|<br />
''myhostname''<br />
}}<br />
<br />
Complete the [[network configuration]] for the newly installed environment. That may include installing suitable [[network management]] software.<br />
<br />
=== Initramfs ===<br />
<br />
Creating a new ''initramfs'' is usually not required, because [[mkinitcpio]] was run on installation of the [[kernel]] package with ''pacstrap''.<br />
<br />
For [[Install Arch Linux on LVM#Adding mkinitcpio hooks|LVM]], [[dm-crypt|system encryption]] or [[RAID#Configure mkinitcpio|RAID]], modify {{man|5|mkinitcpio.conf}} and recreate the initramfs image:<br />
<br />
# mkinitcpio -P<br />
<br />
=== Root password ===<br />
<br />
Set the root [[password]]:<br />
<br />
# passwd<br />
<br />
=== Boot loader ===<br />
<br />
Choose and install a Linux-capable [[boot loader]]. If you have an Intel or AMD CPU, enable [[microcode]] updates in addition.<br />
<br />
== Reboot ==<br />
<br />
Exit the chroot environment by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R /mnt}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
Finally, restart the machine by typing {{ic|reboot}}: any partitions still mounted will be automatically unmounted by ''systemd''. Remember to remove the installation medium and then login into the new system with the root account.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like creating unprivileged user accounts, setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=User_talk:Lahwaacz&diff=700010User talk:Lahwaacz2021-10-26T17:43:16Z<p>Oliver: clarify same footing some more</p>
<hr />
<div>== bot checking links after move ==<br />
<br />
Hi, re [[Talk:Touchpad Synaptics#adding libinput alternative]]. [[Touchpad Synaptics]] has 100+ backlinks and the more important ones - a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of [[Touchpad Synaptics]] and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:36, 26 September 2015 (UTC)<br />
<br />
:Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a [[UUID]] page, which was later generalized and renamed to [[Persistent block device naming]] and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace <nowiki>[[pacman|Install]]</nowiki> with <nowiki>[[Install]]</nowiki> etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:01, 26 September 2015 (UTC)<br />
<br />
::Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [https://wiki.archlinux.org/index.php/Special:WhatLinksHere/Beginners'_Guide]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:02, 26 September 2015 (UTC)<br />
<br />
== mkosi ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=Systemd-nspawn&diff=0&oldid=491975 revert]: You can use mkosi also to create a container/directory tree (-t directory). So it can do the same and more. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 11:33, 1 October 2017 (UTC)<br />
<br />
:Alright, how is the "more" relevant to systemd-nspawn though? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:30, 3 October 2017 (UTC)<br />
<br />
::Hi, mkosi let's you create images (or directory trees) of various different distributions and allows you to do things like setting the root-password or installing additional packages. systemd-nspawn alows you to boot such images/directory trees. So I thought mentioning mkosi as alternative to manually creating a container with pacstrap or debootstrap would be worth it. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 22:23, 5 October 2017 (UTC)<br />
<br />
== Waking from suspend with USB device ==<br />
<br />
Hi Lahwaacz, thanks for your input on this topic.<br />
Can you help me a bit further, I know the USB host controller and the USB device are different things but I thought that enabling the host controller was not necessary anymore, see [https://www.spinics.net/lists/linux-usb/msg53661.html].<br />
In my case all the {{ic|driver/*/power/wakeup}} are all enabled by default and the {{ic|/proc/acpi/wakeup}} as well.<br />
Anyway I have added a step in my explanations to identify the path awaiting for more clarity.<br />
<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 21:57, 16 January 2018 (UTC)<br />
<br />
:Hi, thanks for the link, it's entirely possible that something changed since the section was written. However, in my case only the keyboard device has wakeup enabled by default: {{bc|<nowiki><br />
$ for f in /sys/bus/usb/drivers/usb/*/power/wakeup; do echo "$f: $(cat $f)"; done<br />
/sys/bus/usb/drivers/usb/1-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/2-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-11/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-12/power/wakeup: enabled<br />
/sys/bus/usb/drivers/usb/3-13/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-4/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb2/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb4/power/wakeup: disabled<br />
</nowiki>}}<br />
:But in practice it seems to wake up the system even without the host controllers enabled for wakeup... It might also depend on some BIOS/firmware settings but if it works by default on most systems then I think the host controller settings could be removed again.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:14, 19 January 2018 (UTC)<br />
<br />
== Are supported local/remote destinations important for choosing a backup program? ==<br />
<br />
You [[Special:Diff/525550|reverted]] my edit adding supported backup destinations to [[Synchronization_and_backup_programs]]. This is puzzling to me. Here are some thoughts:<br />
* if choosing any backup program, the ability to send the backup off-site vs only on a local disk is a key feature consideration. Perhaps *the* key feature: one helps me recover in case my house gets burglarized or burns down, and the other does not. This is a much more important feature consideration than, say, whether the program is written in Go or Mono (something that has a full column). I think it's hard to disagree on that.<br />
* Given this, I am very puzzled you would use the term "useless" in the revert message.<br />
* I assume you didn't like that the table got even bigger (it didn't fit into the layout even before). I don't like it either, but perhaps the revert should have said "can you put this somewhere else, not in this already-too-big table?"<br />
* On a personal note, when I provide feedback or give opinion on somebody else's work, I'd like to be constructive and kind, instead of aggressive and putting people down. Just a thought. Thanks for listening.<br />
<br />
[[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 17:38, 11 June 2018 (UTC)<br />
<br />
:No because you can use any remote back-end with any backup application by just running one command / writing the backups to a [[FUSE]] (if available).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:39, 12 June 2018 (UTC)<br />
<br />
::Hmm, by that reasoning we don't need the Arch package repository, as long as we have source code and makepkg. Or Perl, if we have bash and awk. But even then, and if all the fuse backends existed (I doubt they do), and if it were easy to set all of them up (another thing I doubt), do you indeed believe that running something written to read/write local files will be just as efficient backing up gigabytes of data to a remote repository as something that is specifically optimized for that use case? Note that backing up, say, daily, a typical hard drive via tpyical consumer broadband is still quite a bandwidth challenge in many places today. What about we add this info, and remove (or merge) some other columns to make the table smaller? {{Unsigned|18:08, 12 June 2018|Jernst}}<br />
<br />
:::Your comparisons don't make sense. Mind the slash in my response, you do not need a FUSE implementation, a simple CLI suffices. You do not need to "set all of them up", you only need one. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 18:47, 12 June 2018 (UTC)<br />
<br />
::::If you ever attempt to help a normal user set up a reliably-working off-site backup strategy, think of this discussion. In the meantime, this is all the time I'm going to spend on a discussion that has such repeated gems in it as "makes no sense" without explaining why you think so. Have a nice day. [[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 18:54, 12 June 2018 (UTC)<br />
<br />
== The pip section in [[Python package guidelines]] ==<br />
<br />
Hi, you wanted the warning about using pip or wheels restored but accidentally(?) reverted my whole set of changes. I redid them, leaving the warning in place. – [[User:Flying sheep|flying sheep]] 08:17, 8 March 2019 (UTC)<br />
<br />
:Full revert was intentional, because the "wheel" section is not a full replacement for "pip" because there are packages which don't provide wheel files. As I said in the edit summary, there is no reason to recommend one or the other due to the warning. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 8 March 2019 (UTC)<br />
::That still doesn’t explain why you reverted the first part, that had nothing to do with the pip/wheel section and simple improves the files.pythonhosted.org URLs. I restored that one while we’re discussing the pip/wheel section. And about that: There’s no reason to use pip for anything else, and pip is only used because some people (me included) didn’t understand that you can install most wheels by just extracting them to the correct location. So what do you think is missing from my wheels section that the former pip section had? – [[User:Flying_sheep|flying sheep]] 11:41, 11 March 2019 (UTC)<br />
<br />
:::If you didn't notice, the page includes "guidelines" in the title. So the page should contain only common and recommended ways to do things, not everything that is possible to do. If you think that your way to install "wheels" should be followed by everybody, feel free to discuss it on the talk page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:26, 11 March 2019 (UTC)<br />
::::Well, extracting static archives sounds much more recommended than running pip with like 7 options to make it behave. I added a talk item: [[Talk:Python package guidelines#Remove_pip_section_in_favor_of_wheels_section?]] – [[User:Flying_sheep|flying sheep]]<br />
<br />
== wpa_supplicant ==<br />
<br />
Regarding https://wiki.archlinux.org/index.php?title=WPA_supplicant&diff=577215&oldid=577167, one person ran into this problem in March of this year and spent too much time diagnosing it:<br />
<br />
https://bbs.archlinux.org/viewtopic.php?id=244950<br />
<br />
It took me a few days to find the problem. I want to make sure the next time someone encounters it, they easily find relevant information about what the cause is. Since you've reverted my edits to both netctl and wpa_supplicant, what do you suggest?<br />
<br />
--<br />
<br />
[[User:Pooryorick|Pooryorick]] ([[User talk:Pooryorick|talk]]) 08:24, 18 July 2019 (UTC)<br />
<br />
== F2FS and GRUB ==<br />
<br />
Hello. :) I'm here to address a recent disagreement. I noticed a reversion of my edit regarding the F2FS filesystem, in particular regarding the configuration file to edit (with you representing /boot/grub/grub.cfg and me representing /etc/default/grub). I run F2FS on my daily driver with an encrypted root filesystem and encrypted boot on a separate partition, and have never had to touch grub.cfg. I only automatically generate it. It's possible to use either, but /etc/default/grub would make more sense as a recommendation in my mind because grub.cfg has the potential to be overwritten during updates, whereas /etc/default/grub doesn't. <br />
<br />
If there's a compelling reason to use grub.cfg over /etc/default/grub, please let me know. ^^ I'm always eager to learn more about Arch. I don't want to get in a reversion war so I've left your change untouched for the time being.<br />
<br />
[[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 00:17, 8 September 2019 (UTC)<br />
<br />
:The reason is explained in the section: "If GRUB is used with an unsupported filesystem it is not able to extract the UUID of your drive so it uses classic non-persistent /dev/sdXx names instead." If it does not apply to F2FS, it should be made clear. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:29, 8 September 2019 (UTC)<br />
<br />
::You can specify UUID's in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, so my proposed solution would work for F2FS and other unsupported filesystems, without the burden of manually editing grub.cfg. If there's anything I need to clarify or something else I'm missing, just let me know. :) [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 19:37, 8 September 2019 (UTC)<br />
<br />
:::The {{ic|1=root=}} parameter is not supposed to be in GRUB_CMDLINE_LINUX_DEFAULT, regardless if UUID is used or not. ''grub-mkconfig'' automatically detects the root filesystem and adds the appropriate {{ic|1=root=}} parameter based on GRUB_DISABLE_LINUX_UUID. In any case, your change to the paragraph does not make sense. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:02, 8 September 2019 (UTC)<br />
<br />
::::It could simply be because I use full disk encryption, and adding a kernel parameter for the encrypted disk's UUID is correct in that situation. You're more experienced with contributing to the wiki, so I guess I'll defer to your judgment. It felt like a reasonable edit and solution to me and I don't see the downside to including it in GRUB_CMDLINE_LINUX_DEFAULT. [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 05:38, 9 September 2019 (UTC)<br />
<br />
== dracut executable link ==<br />
<br />
Hello, your last edit on the dracut page (https://wiki.archlinux.org/index.php?title=Dracut&oldid=596388) that undid my 'Link to direct "make executable" section for executable link' commit states: "the redirect executable points exactly to that section", but it doesn't. Following the [[executable]] link just points to the top of the Help:Reading page.<br />
<br />
{{unsigned|17:06, 28 January 2020|Krathalan}}<br />
<br />
:In that case your browser probably does not work correctly, because the redirect [https://wiki.archlinux.org/index.php?title=Executable&redirect=no really points to the section]. Or MediaWiki, there was a bug several years ago... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 28 January 2020 (UTC)<br />
<br />
:: How strange... thanks for pointing that out. It does indeed appear to be some issue with my Firefox configuration. [[User:Krathalan|Krathalan]] ([[User talk:Krathalan|talk]]) 19:51, 28 January 2020 (UTC)<br />
<br />
== Getting install.php work in DokuWiki ==<br />
<br />
Hi, than you for having undone my contribution and pointed to the right solution on [[Dokuwiki#Configuration]]. Indeed I had read this solution before, but I was misled by the condition "if you are using lighttpd or nginx and your PHP version is lower than 7": as I use Apache with php v. 7.4.3 I didn't take it into account. Do you know what a correct rephrasing could be? Maybe it should be deleted?<br />
<br />
Also, I think that, at the end of this same section, one should add something like "verify that {{Pkg|php-gd}} is installed and restart {{ic|php-fpm.service}}".<br />
<br />
Naturally I can do it myself, but I prefer to ask before.<br />
[[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 17:31, 19 February 2020 (UTC)<br />
<br />
:Hi, apparently it depends on whether you had {{ic|open_basedir}} set previously or not. I've changed the page, feel free to update the gd extension. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:16, 19 February 2020 (UTC)<br />
<br />
::Thank you! However, while, I didn't have {{ic|open_basedir}} set previously, I couldn't access ''install.php''. I suspect there is another thing to do, since the configuration editor in DokuWiki complains that it cannot modify the configuration files although ownership and permissions are correctly set for the relevant symlinks, directories and files, and so is {{ic|open_basedir}}. However I can edit my pages. Maybe a return from a new user with a fresh installation would be more useful, though. [[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 08:20, 20 February 2020 (UTC)<br />
<br />
== Dead link in Simple stateful firewall#See Also ==<br />
<br />
Hi, Jakub. I am about [https://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&diff=599725&oldid=599717 this] edit. I tried to follow that link one more time and it is not require entering captcha. I am not see any content limitations and my colleague (he uses Tor) does not see them too. I am not sure how it works, so I leave it on your descision. -- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 14:29, 1 March 2020 (UTC)<br />
<br />
:Well, maybe it depends on the location from which the request comes. But I don't know how it works either... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:33, 1 March 2020 (UTC)<br />
<br />
::my guess is it returns captcha for crawlers only -- [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 01:59, 2 March 2020 (UTC)<br />
<br />
:::I'm getting it in my browser... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 2 March 2020 (UTC)<br />
<br />
== SystemD user units depending on graphical session ==<br />
Hi,<br />
regarding reverting my addition to [[Systemd/User]], could you please explain why? I referenced [[https://www.freedesktop.org/software/systemd/man/systemd.special.html]] which directly contradicts what you said in your summary.<br />
<br />
{{unsigned|19:53, 5 May 2020|Fuero}}<br />
<br />
:The note in [[Systemd/User#How it works]] still applies - systemd services are never per-session, but per-user. The service does not magically get the correct DISPLAY or WAYLAND_DISPLAY variable, it does not work if you have multiple sessions per user, etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:45, 6 May 2020 (UTC)<br />
<br />
== Plymouth ==<br />
<br />
Actually with just Plymouth it does not work properly. Even 0dd17y had the same issue in https://bbs.archlinux.org/viewtopic.php?id=220900.<br />
<br />
The reason I did not file a bug report is that it is anyway fixed in the git version and the latest release (0.9.4) is around 2 years behind master<br />
<br />
{{unsigned|09:50, 6 May 2020|M.Srikanth}}<br />
<br />
:So if you don't have to file a bug report, add a full troubleshooting entry or at least properly reference your inline note instead of resorting to plain "if that does not work, try this instead". -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:15, 6 May 2020 (UTC)<br />
<br />
== [Bitcoin core] build the code and run the test suites ==<br />
<br />
Hello,<br />
<br />
This week, I managed to build the Bitcoin code and run all the test suites with the help of this page: https://jonatack.github.io/articles/how-to-compile-bitcoin-core-and-run-the-tests<br />
<br />
Archlinux has two particularities:<br />
* being in rolling release, it takes to manually use the library {{ic|Berkeley DB (BDB) v4.8}}<br />
* the {{ic|/tmp}} directory is by default limited to half the size of the Ram<br />
<br />
For these reason, maybe it could be interesting to have a page in the wiki to explain how to build the Bitcoin core?<br />
<br />
Cheers,<br />
<br />
Thomas<br />
<br />
[[User:Thomasb|Thomasb]] ([[User talk:Thomasb|talk]]) 20:29, 9 May 2020 (UTC)<br />
<br />
:I don't think that this is useful. There is the {{AUR|bitcoin-core-git}} package and nothing more should be needed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:53, 26 May 2020 (UTC)<br />
<br />
== Double linefeed results in extra line ==<br />
<br />
If you look at templates that end with double linefeed before noinclude this would result in extra line in resulting page.<br />
<br />
It may be a minor point but since you are perfectionist about wikitext I should mention this is a tradeoff and it results in slightly worse result.<br />
<br />
Removing just one linefeed removes the problem while still allowing it to not jumble all the tags into same line.<br />
<br />
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:30, 11 May 2020 (UTC)<br />
<br />
:If this is about [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=next&oldid=612179], the spaces I added back are not included when the template is used elsewhere, because the spaces are inside the noinclude tags. The extra space is only on the template page itself, but it does not result from template inclusion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:41, 11 May 2020 (UTC)<br />
<br />
::OFC, I mean the template page render has extra line. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 21:21, 11 May 2020 (UTC)<br />
<br />
:::I agree with [[User:Svito|Svito]], isn't it good to delete the extra blank lines? -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 05:39, 12 May 2020 (UTC)<br />
<br />
::::OK, let's do it. [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=616382&oldid=612181] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:47, 26 May 2020 (UTC)<br />
<br />
== Re: lighttpd: remove python2 version ==<br />
<br />
Instead of removing the example we could as well add an example using a Python3 library like https://pypi.org/project/flup6/.<br />
<br />
{{unsigned|15:23, 18 May 2020|Gruentee}}<br />
<br />
:Feel free to add it if you find it useful. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:56, 18 May 2020 (UTC)<br />
<br />
== Xbindkeys removal ==<br />
<br />
Hi, just wondering why you [https://wiki.archlinux.org/index.php?title=Xbindkeys&diff=617675&oldid=617670 removed my edit] from [[Xbindkeys]]? The xbindkeys page has a number of quick tips but no mention of how to bind anything to the Print Screen key so I thought it would be useful to add. -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 02:27, 3 June 2020 (UTC)<br />
<br />
:Giving examples for all keys on the keyboard is useless, there is [[Xbindkeys#Identifying keycodes]] which teaches how to find the keycodes and keysyms of any key. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 3 June 2020 (UTC)<br />
<br />
:: So how come you left the examples for the volume up/down and brightness? What is different between those examples and a screenshot example? Aren't more examples better to save people from hunting all over the place trying to piece things together themselves? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 14:03, 4 June 2020 (UTC)<br />
<br />
:::The difference is that when it comes to volume control, there are 1 or 2 options for the 99% most common cases, but for screenshot taking there are dozens of different options. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:15, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for edit to XDG Base Directory page regarding python_history ==<br />
<br />
I understand the justification for reverting the change I made, however I would like to point out that similar entries on the page (such as Maven) also have instructions for what contents to put in files (even though there is native documentation for those settings). Additionally, it took me a bit of re-reading on the linked Python documentation to reason out how the documentation's example needed to be modified, since it's not clear from the Python documentation whether placing such code in the PYTHONSTARTUP file will actually ''override'' the default behavior. [[User:Varriount|Varriount]] ([[User talk:Varriount|talk]]) 20:44, 20 June 2020 (UTC)<br />
<br />
:Even maven's note can be [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=631704&oldid=631630 shortened]. The notes in the table must be as short as possible, there is no place for extended explanations or long code snippets like in the upstream documentation. If the Python's documentation is not clear enough, I don't think any note in a massive convoluted table will ever be better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:47, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for Backlight page ==<br />
<br />
Hi, you reverted my change to [[Backlight]] page that mentioned WIP patches for controlling OLED panel brightness. I don't really understand justification for reverting it since currently the page says that OLED brightness can be controlled only by changing gamma ramp. That is wrong - since it's not the only way - these panels can control brightness with a PWM. Moreover controlling brightness with gamma ramp is not optimal - it essentially reduces dynamic range, i.e. at 50% you have 7 bits per pixel, at 25% - 6 bit per pixel, etc. That results in banding artifacts at lower brightness level.<br />
<br />
As far waiting for the patches to be merged before mentioning it there - it'll take ~3-6 months (yes, that's the process) and I haven't found *any* reference to these changes on the internet - everyone recommends using gamma ramp instead of fixing it properly. I'm absolutely sure that having information about these patches would not hurt [[User:Anarsoul|Anarsoul]] ([[User talk:Anarsoul|talk]]) 15:56, 30 June 2020 (UTC)<br />
<br />
:Linking to a repo which which has 2 custom commits on top of some arbitrary development version of the Linux kernel tree is not helpful for users. Nobody will compile directly from this repo which is already significantly outdated compared to recent kernel versions and there is no indication if the patches actually work with newer (or older) kernels. We can mention the PWM control as a general concept though. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:32, 12 August 2020 (UTC)<br />
<br />
== Automatic template correction ==<br />
<br />
Per [[Help:Template#Style]], templates should be used with the capitalization shown in the examples in their pages, so {{ic|&#123;{AUR&#124;...}} is correct, while {{ic|&#123;{aur&#124;...}} is not.<br />
<br />
However, there are pages that don't respect that rule (e.g. [[Android_Debug_Bridge]] until recently).<br />
<br />
I beleive this correction should be easy to implement using a bot. What do you think?<br />
<br />
{{unsigned|07:24, 25 August 2020|Relrel}}<br />
<br />
:Yes, this should be easy, but the bot should not make a huge amount of simple style-only changes - they should be combined with corrections for more complex rules. Anyway, there is an idea to create a [https://github.com/lahwaacz/wiki-scripts/issues/22 style linter] for the ArchWiki rules. Would you like to help? ;-) – [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:21, 25 August 2020 (UTC)<br />
<br />
== Failed to create tun device ==<br />
<br />
I don't understand your reason for [[https://wiki.archlinux.org/index.php?title=NetworkManager&diff=0&oldid=634880 removing my section in NetworkManager]]. Could you elaborate?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 07:40, 11 September 2020 (UTC)<br />
<br />
:You can't use [[systemd-networkd]] and [[NetworkManager]] at the same time. Even if you don't have any ''.network'' file for systemd-networkd, you can't solve NetworkManager's problems with systemd-networkd. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:43, 11 September 2020 (UTC)<br />
<br />
::Ok, thanks, in this case it solved the error I got. Now the VPN works. Do you have an idea about how to solve it without systemd-networkd?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 22:27, 11 September 2020 (UTC)<br />
<br />
:::You should really fix the permission problem for {{Pkg|networkmanager-openvpn}}. The tun interface should be managed by OpenVPN which needs rights to create it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 12 September 2020 (UTC)<br />
<br />
::I don't think this statement is entirely correct. [[systemd-networkd]] and [[NetworkManager]] can happily co-exist together if they are managing different interfaces. I unfortunately don't have a reference to point to this, but I came across this being mentioned a couple of times on forums. I personally use [[NetworkManager]] on my laptop to handle wifi, while [[systemd-networkd]] is in control of virtual ethernet and bridges for all my [[systemd-nspawn]] instances. [[User:Romstor|Romstor]] ([[User talk:Romstor|talk]]) 03:24, 12 September 2020 (UTC)<br />
<br />
== [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&oldid=636526/ XDG Base Directory]: Undo revision 636525 ==<br />
<br />
Dear Lahwaacz,<br />
<br />
maybe my changes were to rushed and from my point of view only. But I have two points to consider:<br />
<br />
# If I put the quotes around my vimrc and source it from my .bash_profile, I get the vim-error E471 (Argument required). Without quotes, this doesn't happen. So this change based on experience.<br />
# The rtp should includes directories, which are needed at runtime. (in plain vim e.g. ~/.vim). This is not a typical configuration directory. My mistake was, that I supposed that everyone put their vim plug-ins in $XDG_DATA_HOME and not in $XDG_CONFIG_HOME, because from my point of view a plug-in doesn't belong to the configuration. Maybe it is a good idea to add a remark, which explains the addition of $XDG_CONFIG_HOME to the rtp.<br />
<br />
[[User:Grrr|Grrr]] ([[User talk:Grrr|talk]]) 13:53, 26 September 2020 (UTC)<br />
<br />
# Quotes are there because $XDG_CONFIG_HOME may contain spaces.<br />
# It's not only about quotes - the runtimepath has subdirectories for color schemes, keymaps, autoload scripts etc.<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 26 September 2020 (UTC)<br />
<br />
== Readability in Wiki ==<br />
<br />
I noticed that you and the other admins and moderators often want sentences to continue endlessly, without line breaks.<br />
For example in the introduction of [[Wayland]].<br />
<br />
I think it would be better to have more seperated sentences, so it is easier to read and "important" information is easier visible for people.<br />
I don't know who is responsible, but maybe some options in MediaWiki (or whatever this wiki software is) could be changed as well, to make make line breaks etc. easier and reduce the height-space (if you know what I mean) between sentences, so it looks better, even though line breaks are used.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:38, 15 October 2020 (UTC) G3ro<br />
<br />
:I don't know exactly what you mean. Is it about the readability of the rendered HTML or the "source code" of the page? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:15, 15 October 2020 (UTC)<br />
<br />
:: Well I guess it can be about both. But mainly it is about what people see on the page.<br />
:: There are three seperate topics I mentioned:<br />
<br />
:: 1. Use line breaks: I would like to use more line breaks, because if you have long sentences that are written after each other without line breaks, it gets "harder" to recognize when the next sentence starts.<br />
:: While I agree to what you said somewhere, that sentences that belong directly together, should be written in one "paragraph", it would be useful for sentences that cover (slightly) different "topics" to be visibly parted.<br />
<br />
:: 2. Adjust margin options: I notice that when line breaks are used, there is a vertical space added between two sentences. Just like in this post. If you would use line breaks more often, this is a little too much spacing in my oppinion.<br />
<br />
:: 3. Potential options to make line breaks easier: It would be very convenient if a line break in the source code would lead to a line break in displayed text as well, instead of needing to add an empty line.<br />
<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:33, 15 October 2020 (UTC) G3ro<br />
<br />
:::OK, now I understand. I agree that splitting different topics usually improves legibility, but they should be split into separate paragraphs and not just by line breaks (e.g. using the &lt;br> tags). Paragraphs are semantic units whereas line breaks inside a paragraph are usually typographic errors.<br />
:::Also note that such splitting alone may not be enough to improve the text flow. For example, if we consider the intro for [[Wayland]], the second sentence about XWayland would not constitute a good paragraph - it is just a plain statement and the new topic is not nicely introduced. Ideally, you'd split the topic and make some wording changes for the second paragraph.<br />
:::As for the margin options, that is the difference between paragraph splitting and non-semantic line breaks. In my opinion, the styling is correct in this respect, as paragraphs should be discernible. You mentioned that you like line breaks to easily recognize where a sentence ends - but reading should be based on whole paragraphs, not sentences. There should be no reason to skip anything in the middle of a paragraph, otherwise it should be probably split into multiple paragraphs or otherwise rephrased.<br />
:::If you find it hard to follow a long sentence horizontally on a wide screen, we might consider enforcing some maximum width for the whole content. I think the readability would be better, since there would be more top-to-bottom eye movement at the cost of left-to-right-and-back.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:59, 15 October 2020 (UTC)<br />
<br />
== Xorg parentheses ==<br />
<br />
I actually think that X(org) is very useful to imply that it is one and the same thing.<br />
<br />
It might even be more confusing now, as we use both Xorg and X, because the wiki title and the package titles are Xorg.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:30, 17 October 2020 (UTC) G3ro<br />
<br />
:Well the conventions should be established on the [[Xorg]] page, not anywhere else... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:36, 17 October 2020 (UTC)<br />
<br />
:: Imo the conventions are established by upstream and they use a wide variety of X, X.org, X(org), Xorg etc.<br />
:: As I said I always prefer X(org) because then it is clear, that both are same thing.<br />
:: But ultimately it's your decision. <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:43, 17 October 2020 (UTC) G3ro<br />
<br />
:::When upstream is not capable of making a unambiguous decision, it makes sense that other projects pick some option and stick with it wherever they can to keep at least some consistency. So for this wiki, pages should use the same style as the [[Xorg]] page. But feel free to start a discussion about this in [[Talk:Xorg]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:56, 17 October 2020 (UTC)<br />
<br />
== SSHFS - systemd edit ==<br />
<br />
The edit was removed because "there is no advantage over using fstab entries".<br />
<br />
Is not only about the dis/advantages of the systemd option, is about that it is another possibility to achieve the task, that is why it was created in another level and the fstab section was left alone.<br />
<br />
Reconsider the edit as it presents another option which people can use.<br />
<br />
[[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 16:22, 22 October 2020 (UTC)<br />
<br />
:There is no need to use anything else, fstab just works well enough. Configuring mounts with systemd services is not a good idea - it is much more bloated than fstab and not the right tool for it. If anything, a different type of systemd units should be used: {{man|5|systemd.mount}}. But creating the mount units manually is still pretty useless since everything can be configured in fstab and systemd will generate the unit for you. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:22, 22 October 2020 (UTC)<br />
<br />
:: It is about the ability to use the user's .config file and all the proper options that are saved there. Also systemd gives the possibility to use different targets, so the user could mount it when an specific user logs in or when a graphical session starts. I could argue that bad a modification of fstab could lead to a system that doesnt boot, but such poorly configured systemd unit file just fails and the system is fine. Just give the user the information and let it decide what they can use depending on their use case. [[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 08:08, 24 October 2020 (UTC)<br />
<br />
:::You can configure systemd targets in fstab using the {{ic|x-systemd.wanted-by}} and {{ic|x-systemd.required-by}} options, there are also {{ic|nofail}} and {{ic|noauto}} options. Please read the {{man|5|systemd.mount}} manual.<br />
:::Using hosts from the user's {{ic|.ssh/config}} is the only thing which is not possible with fstab, but this does not warrant using the wrong tool for the task. Simple copy the full {{ic|user@hostname}} into fstab and you're done.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:47, 24 October 2020 (UTC)<br />
<br />
== [[Self-encrypting drives]] ==<br />
<br />
Hi, I'd like to respectfully disagree with the rollback. It's specific to sedutil that with most commands you need to input /dev/nvme0 (when encrypting the device) but for the sleep commands it requires /dev/nvme0n1 or it fails with a very unspecific error (Error saving the password to the kernel errno = 25), as found out in the discussion https://github.com/Drive-Trust-Alliance/sedutil/issues/90<br />
<br />
All in all I believe that it is important to keep this piece of information which was found out in a long discussion between the reporter and the developers. I ran into it and I believe many people may run into it, considering most of the new SSD will be NVMe. Best, [[User:Przemub|Przemub]] ([[User talk:Przemub|talk]]) 13:34, 28 October 2020 (UTC)<br />
<br />
:OK, then it makes sense. But it should be probably explained before, not in the section about the sleep command. Also please add the link to the note as a reference. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:27, 28 October 2020 (UTC)<br />
<br />
== Nvidia Installation ==<br />
<br />
The whole guide is unnecessary long and overcomplicated formulated.<br />
Shorter is better, most people will know their graphic card for example, so the determination etc. is only optional.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:21, 10 November 2020 (UTC) G3ro<br />
<br />
:Moving some info to some other page and leaving a tip behind does not make it shorter, but harder to follow. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:36, 10 November 2020 (UTC)<br />
<br />
== Btrfs layout ==<br />
<br />
Hi, Lahwaacz<br />
<br />
Thanks for maintaining [[Snapper]]! However I think the layout is not openSUSE specific and beneficial to all btrfs users. Can you elaborate your reason of undoing the edits? IMO the previous 'simple layout' complicates the rollback procedure.<br />
<br />
Cheers,<br />
[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 07:26, 3 December 2020 (UTC)<br />
<br />
:It is not overcomplicated, it is just doing things right. You can read about that in the forum thread, see the first note in [[Snapper#Suggested filesystem layout]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:24, 3 December 2020 (UTC)<br />
<br />
::Anyway I've moved the guides to my user page. It's not that I haven't read the 5-year-old forum post, it's that before the current layout I followed that post and resulted in a not fully rolled-back system. That post also sourced (then current) information from openSUSE. openSUSE has since massively overhauled the layout, as I pointed out in an edit you undid earlier.[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 09:02, 3 December 2020 (UTC)<br />
<br />
::Since last message I've extensively documented the new layout at [[User:I2Oc9/Btrfs_subvolumes]] and [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption]]. Have a look for yourself. Nothing new really, but IMO [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my take]] is much more simpler and complete than the supposedly [[Snapper#Restoring_/_to_a_previous_snapshot_of_@|simpler one]]. That one does not leverage native {{ic|snapper rollback}} or {{Pkg|grub-btrfs}}, among other things. I strongly suggest you try if you have time. [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 11:55, 3 December 2020 (UTC)<br />
<br />
::Actually if you look closely, none of [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my recovery methods]] is specific to [[User:I2Oc9/Btrfs_subvolumes#A_new_kind_of_layout|the new 'complex' layout]], it will work totally fine with the old one. I just don't think moving @ around in live environment is appropriate.<br />
<br />
::On the other hand, the layout recommendation has been updated by openSUSE [https://en.opensuse.org/SDB:BTRFS], why stick with the old one? [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 12:37, 3 December 2020 (UTC)<br />
<br />
:::The main reasons why I reverted your edits on the [[Snapper]] page are: 1) it was a huge change which was not discussed previously as required by [[ArchWiki:Contributing#The 3 fundamental rules]], and 2) it has some elements which do not apply to Arch (see below). If you wish to propose a better layout of the subvolumes, it should be discussed in [[Talk:Snapper]] first. Your user pages would serve as great drafts.<br />
:::Note that the current suggested layout is not ''flat'' in the sense of [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|your section]] - it has a separate subvolume for {{ic|.snapshots}} so it does not lead to the recursive mess. So your proposed layout seemed very similar to the current suggested layout. The real difference is which subvolume gets mounted at {{ic|/}}, but I did not find it explained anywhere on the Snapper page before I reverted the changes (I get it now from your user page). I also did not find a proper documentation of the openSUSE's layout - it seems to be just the product of their installer and the documentation only deals with the result, saying at most that [https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-snapper.html#sec-snapper-snapshot-boot the subvolume configuration must not be changed] for rollbacks to work.<br />
:::Now the openSUSE-specific elements: some Arch packages actually install software into {{ic|/opt}}, so the recommended layout should not suggest a separate subvolume for this path. Even more importantly, the pacman database is located at {{ic|/var/lib/pacman/local/}} and it must be rolled back along with the system, so there should be no separate subvolume for {{ic|/var}}. Instead, users should be encouraged to create (even nested) subvolumes for specific data directories under {{ic|/var}}, such as {{ic|/var/log}}, {{ic|/var/tmp}}, {{ic|/var/cache/pacman}}, {{ic|/var/lib/machines}}, etc.<br />
:::Finally, the suggested layout should not be GRUB-specific, there should be no recommendations regarding a boot loader. Sure it is useful to include non-trivial tips, but people may actually use a different boot loader.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:31, 4 December 2020 (UTC)<br />
<br />
::::Thanks for your detailed reply. I admit that I'm not knowledgeable on the intricate differences between distributions and shouldn't have made the changes without properly discussing them first.<br />
::::Yes, I get that the current layout is not [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|the one described in this section]] and indeed properly separates {{ic|/.snapshot}} and {{ic|/}}. The layout I proposed attempts to add some "niceties" such as supporting multi-distribution installations (complex and unnecessary, I agree) and bring the openSUSE layout here, which is a mistake, as you've pointed out.<br />
::::As for GRUB, since I use LUKS all the time and it's the only bootloader supporting encrypted {{ic|/boot}} on Btrfs on LUKS1, I really didn't think of any other possibilities.<br />
::::I will incorporate your recommendations to my user page and add a new section in [[Talk:Snapper]] pointing to those pages.<br />
::::Cheers -- [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:09, 4 December 2020 (UTC)<br />
<br />
:::::I've adopted [[Install_Arch_Linux_on_ZFS#System_datasets|Archlinux Root on ZFS layout]] to [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Create_subvolumes|my proposal]]. [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:56, 4 December 2020 (UTC)<br />
<br />
== Reflector Revert ==<br />
<br />
Hi Lahwaacz, about your [https://wiki.archlinux.org/index.php?title=Reflector&oldid=643749 revert], it seems like there's precedence for including AUR packages that replicate the code on the wiki. For example, in [[dash#Relinking /bin/sh]].<br />
<br />
In addition, I believe that there's value for linking the AUR package because it allows a simpler user experience where the AUR package is maintained for them. That way, if it is ever updated, they can easily fetch the update instead of religiously checking the wiki page (which most users probably don't do).<br />
<br />
Thanks!<br />
<br />
[[User:Denton-l|Denton-l]] ([[User talk:Denton-l|talk]]) 01:52, 7 December 2020 (UTC)<br />
<br />
:That precedence was only created by [https://wiki.archlinux.org/index.php?title=Dash&type=revision&diff=561587&oldid=518398 yourself]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 5 May 2021 (UTC)<br />
<br />
== firefox zoom ==<br />
<br />
"no reason to zoom manually, see HiDPI)" - fractional scaling doesn't work [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 26 December 2020 (UTC)<br />
<br />
:That should be explained in [[HiDPI#Firefox]] anyway. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:48, 26 December 2020 (UTC)<br />
<br />
::it's good to have this mentioned somewhere clearly so people know about it before they say "fonts on linux suck" [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 15:51, 29 December 2020 (UTC)<br />
<br />
== Intel GVT-g edits ==<br />
<br />
Hello Lahwaacz,<br />
<br />
I have noticed that you reverted one of the edits I have performed on [[Intel_GVT-g]].<br />
<br />
About this revert: [https://wiki.archlinux.org/index.php?title=Intel_GVT-g&oldid=648062 Windows problems are out of scope]<br />
<br />
While I understand that the ArchWiki is about ArchLinux, this article in particular mentions Windows in the introduction, and already includes another troubleshooting point about Windows. The issue I have encountered with the black bars is somewhat common, as I have found other people discussing it online, and I really fail to see why not including this piece of information in this article would be better than including it.<br />
<br />
Please, let me know your thoughts. If you think that the point can be improved, I will be happy to do that.<br />
<br />
Ciao,<br />
<br />
[[User:Wilcomir|Wilcomir]] ([[User talk:Wilcomir|talk]]) 09:14, 3 January 2021 (UTC)<br />
<br />
:Well, the existing section about a Windows problem is actually solved by configuring the Linux host. I think anything involving configuration or installation of programs in Windows is not appropriate for long troubleshooting sections. At most, they could be mentioned in a short reference to other sites which describe the problem in detail. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:34, 3 January 2021 (UTC)<br />
<br />
== <s>XDG configuration for Vim</s> ==<br />
<br />
Hi Lahwaacz,<br />
<br />
You have reverted the updated Notes for Vim on [[XDG Base Directory]], because "copy-pasted from a blog post".<br />
<br />
The problem is, not only is the configuration presented currently also copied from a blog post too, but is already 10 years old.<br />
<br />
Would it be OK, if we bring back the more up to date version? Or at least remove the obsolete one and leave link to newer?<br><br />
(Although I think a copy on wiki would be beneficial in case my blog ceases to exist)<br />
<br />
[[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 02:05, 12 January 2021 (UTC)<br />
<br />
:OK let's close this. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:49, 29 August 2021 (UTC)<br />
<br />
== Root on ZFS draft ==<br />
<br />
Hi, I submitted [https://github.com/openzfs/openzfs-docs/pull/104 a Root on ZFS draft] to official doc repo.<br />
<br />
In the draft, the following directories are separated from root filesystem:<br />
home,root,srv,usr/local,var/log,var/spool,var/tmp<br />
<br />
Is this appropriate for Arch Linux? Or do you have any suggestion on the draft?<br />
Any comment is appreciated.<br />
[[User:M0p|M0p]] ([[User talk:M0p|talk]]) 01:28, 23 January 2021 (UTC)<br />
<br />
== Re: undo GRUB - Common installation errors ==<br />
<br />
Concerning your undo of [https://wiki.archlinux.org/index.php?title=GRUB&diff=next&oldid=649799 Add the error message `Could not prepare Boot variable: No space left on device`)]<br />
Is there a better place to for this Information? One can find the solution in various forums, but I thought it could be helpful to have it in this wiki somewhere. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 12:51, 25 January 2021 (UTC)<br />
<br />
:The error message is not specific to the {{ic|/sys/fs/pstore/}} filesystem (which does not even seem to be used by default on Arch...) Where did you find that? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:16, 25 January 2021 (UTC)<br />
<br />
::I did not find anything Arch specific, but this post about Debian helped: [https://donjajo.com/fix-grub-efibootmgr-not-set-variable-no-space-left-device/ Post]. I also found something about [https://askubuntu.com/questions/1072618/could-not-prepare-boot-variable-no-space-left-on-device-grub-install-error-ef /sys/fs/efi/efivars/dump-*] The problem is that the actual efi-partition does not seam to be the problem, there is more than 70% space left. If there is better information to guide the user in the right direction that wuld be more helpful. This is what I found worked, but I admit that I don't know much about how grub operates. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 16:20, 25 January 2021 (UTC)<br />
<br />
:::This wiki ''is'' Arch specific so old posts about Debian or Ubuntu do not apply. Even if they did, this is hardly a ''common'' installation problem. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:29, 26 January 2021 (UTC)<br />
<br />
::::I know that, and would not have put it there if it didn't occur on my Arch Linux installation. If this is something that should not be documented in this wiki, I understand that. Is there any other place you would recommend? An issue for grub-install maybe? [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 22:24, 26 January 2021 (UTC)<br />
<br />
== Kernel Compilation time ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Kernel&diff=next&oldid=650896 link]<br />
<br />
I don't think we should judge information by what is obvious to experts.<br />
People might have experience with compilation of other programs, which mostly is fast, and then there is the kernel which takes forever to compile.<br />
I think it does not hurt anyone to make people aware of it.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:03, 6 February 2021 (UTC)<br />
<br />
:It is an unnecessary information without a definite answer which can even be [https://html.duckduckgo.com/html?q=how%20long%20does%20it%20take%20to%20compile%20Linux%20kernel searched elsewhere]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:23, 6 February 2021 (UTC)<br />
<br />
:: I disagree, with that argument nearly any tip and note is unnecessary. These things are intended to inform users about things that should be taken into consideration and that are different from the norm.<br />
:: Also do you search for the compilation time for every program you intend to compile? I don't.<br />
:: Furthermore this info is included, why not tell it to people directly on the start, so they don't read over it? <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:36, 6 February 2021 (UTC)<br />
<br />
:::If someone wants to compile the Linux kernel, they should obviously expect that it will take ''some time''. Stating that it "can take up to several hours" does not make sense without referring to a specific hardware. Obviously, it will take much longer on a poor laptop than on a powerful workstation with a many-core processor, but people can assume that themselves. Without a reference to a specific hardware, the note is unnecessarily discouraging because the compilation can be as fast as some tens of minutes - it is by far not the most expensive package to compile...<br />
:::As you said, people can find better notes later along with advices to enable parallel build etc. which is all that's needed IMO.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:03, 6 February 2021 (UTC)<br />
<br />
== Wayland style ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Wayland&diff=prev&oldid=650979 link]<br />
<br />
I think in the old version it was much easier to read the "source code", so I don't see why there can't be spaces between it.<br />
Things shouldn't be complicated more than necessary.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:11, 6 February 2021 (UTC)<br />
<br />
:Most templates on the wiki are written without spaces around the |. When we [https://github.com/archlinux/archwiki/pull/32 switch the editor], there will even be syntax highlighting. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:25, 6 February 2021 (UTC)<br />
<br />
== Bluetooth keyboard ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php/Bluetooth_keyboard link]<br />
<br />
On your last change you said "not specific to keyboards, all of this is already mentioned on the Bluetooth page", the point is that this is extremely relevant for bluetooth keyboard since it is required to perform the login! If this little piece cannot be duplicated I would suggest at least to leave a link saying "If you want to autoconnect at boot please refer to...". I'm new here and I would not touch it further, but please evaluate the suggestion (this is because after reading bluetooth keyboard page and not finding the solution I had to look for it on forums)<br />
<br />
{{unsigned|21:17, 20 February 2021|Stevexyz}}<br />
<br />
:Well, basically the whole page is flagged to be merged with the main [[Bluetooth]] page, so it's expected to be incomplete. Other tips may always be found on a more general page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:40, 21 February 2021 (UTC)<br />
<br />
== Re: Steam Needs to be online error ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Steam/Troubleshooting&diff=next&oldid=653073 link]<br />
<br />
The problem here is that DNS resolution in general works already (yes even outside browsers), i.e. <br />
<br />
dig media.steampowered.com<br />
<br />
would run successfully, but the Steam client couldn’t resolve it. The DNS request from 'dig' shows up in my nameserver’s log, the one Steam should send doesn’t. This indicates it might indeed a problem specific to Steam, and it’s not as easy as just say "go fix your DNS resolution", as it already may work correctly for everything but Steam.<br />
<br />
Additionally, at no point does [[Domain name resolution]] even mention nscd, so you effectively removed a fix/workaround for the problem from the Wiki. So I was definitely not "duplicating an article" here. [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 08:12, 22 February 2021 (UTC)<br />
<br />
:Could I please hear your opinion on this? I’d be happy to just add something along the lines of "if you made sure DNS resolution works but Steam still can’t resolve it, try additionally enabling the nscd service" to the Steam troubleshooting page. Unfortounately I don’t know why running the service helps, but I’d still like to give others an easier time finding this solution than I had myself. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 09:15, 28 February 2021 (UTC)<br />
<br />
::Hi, I'm sorry for the delay. Could you test if using a different program for DNS caching (e.g. [[systemd-resolved]]) instead of {{ic|nscd.service}} fixes the problem? If not, then it's probably not due to DNS - {{man|8|nscd}} actually caches more than just DNS. Also if you have a reference to some website where you found about nscd, it would be nice to add it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 28 February 2021 (UTC)<br />
<br />
:::No worries. Using [[systemd-resolved]] for DNS resolution (and caching I guess, I wasn’t aware it does that, too) was a thing I did try, but that didn’t fix it for me. The place I found out about nscd fixing it was actually the [https://bbs.archlinux.org/viewtopic.php?id=263356 Arch forums]. When I search the web for Steam in combination with nscd, all I can seem to find are more forum entries of people that don’t know why that fixes it either. I can try a bit to find out what nscd does to make it work, but I’m not too confident I will be successful. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 14:51, 28 February 2021 (UTC)<br />
<br />
::::Okay, so {{ic|nscd}} allows to [https://man7.org/linux/man-pages/man5/nscd.conf.5.html dis-/enable caching per service], and it’s indeed enabling it for {{ic|hosts}} that makes it work. That’s weird though, since [[systemd-resolved]] has caching enabled by default, and using it for resolution didn’t make {{ic|steam}} work for me. Leads me to think that I didn’t set it up correctly, although resolving via {{ic|dig}} *did* work. Since [[steam]] depends on [[Name Service Switch]], I tried resolving using {{ic|getent}} manually with nscd disabled, but that worked while steam did not. I’m not really sure what to make of this, since I have no idea how this low level networking/resolving stuff works really. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 15:39, 28 February 2021 (UTC)<br />
<br />
:::::Hmm, I don't know the details either. Steam needs the multilib packages so maybe that's part of the problem. Could you add your findings to the section and use [[Template:Expansion]] for the missing details? Maybe someone can figure it out. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:44, 28 February 2021 (UTC)<br />
<br />
::::::Sure, I can do that. I’ll probably need a minute to figure out how to use the template though, but I should have the time later today. Thanks for your input on this. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 17:56, 28 February 2021 (UTC)<br />
<br />
== Removal of website link ==<br />
<br />
Refers to this: https://wiki.archlinux.org/index.php?title=PipeWire&diff=next&oldid=653701<br />
<br />
I don't understand why that has to be removed. The official website should be always worth a mention, even if it is somehow mentioned in the text already.<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:02, 28 February 2021 (UTC)<br />
<br />
:The "See also" section is for additional links, it is not intended as a collection of all links used on a page. Adding links which are clearly mentioned in the appropriate place only clutters the list. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:24, 28 February 2021 (UTC)<br />
<br />
:: There are just three links and only one of them is really useful, the others could maybe even be removed as they link to old blog posts.<br />
:: I can only repeat myself, that things don't always have to be made more complicated than necessary.<br />
:: The official website is a central point which links to many more useful ressources, so it's one link for much information.<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:34, 28 February 2021 (UTC)<br />
<br />
== Removal of bootia32.efi generation procedure from X205TA install page. ==<br />
<br />
Those [https://wiki.archlinux.org/index.php?title=ASUS_x205ta&diff=596239&oldid=562734 instructions] were really straightforward and useful, imho in comparison present ones require too much material to be confident with. I think it's (paradoxically) way easier to generate the file than to configure a `grub.cfg` from zero to boot a live cd. Can we undo the edit? Otherwise we could put them in a new page or section in the GRUB page and link to them maybe. [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 05:07, 4 March 2021 (UTC)<br />
<br />
:If there is something wrong with the information on the [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Booting_64-bit_kernel_on_32-bit_UEFI general page], it should be improved instead of describing the same procedure in a different way on a completely unrelated page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:16, 6 March 2021 (UTC)<br />
<br />
:: I didn't know we had that info in the UEFI article. I think it could be appropriate to insert the [https://en.wikipedia.org/wiki/Template:See_also#Examples See also] archwiki equivalent (which I couldn't find) for UEFI page on top of the aforementioned section, what do you think? [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 13:28, 7 March 2021 (UTC)<br />
<br />
:::Well, the removed section was previously flagged with "Duplicates [[Unified Extensible Firmware Interface#Booting 64-bit kernel on 32-bit UEFI]]"...<br />
:::Also the laptops pages are usually related to most of the general pages on this wiki, adding all of them would be pretty useless. Users should not expect to find everything on a single laptop page, they should always check if there is a general page for their topic with more details.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:58, 7 March 2021 (UTC)<br />
<br />
== Re: Show how to use systemd/Timers with wg-quick@.service ==<br />
<br />
I don't think using service is the appropriate when you want to start Wireguard at boot. For most people connecting to a VPN is not exactly part system startup.<br />
A timer should more appropriate.<br />
[[User:ENV25|ENV25]] ([[User talk:ENV25|talk]]) 10:03, 11 April 2021 (UTC)<br />
<br />
:I don't see how OnBootSec=1min is more appropriate than an automatically starting service. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:19, 11 April 2021 (UTC)<br />
<br />
== USB flash installation medium (BIOS bootable) ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=next&oldid=673926 revert]: "making the partition bootable is discussed below"<br />
Do you mean installing syslinux and `dd` the [gpt]mbr with "discussed below"? This was not enought for my setup (Sandisk Ultra 64GB, Dell XPS 9370) to make the partition BIOS bootable. It did work right after I checked "Legacy BIOS Bootable" checkbox using gnome-disks.<br />
<br />
{{Unsigned|13:42, 30 May 2021 (UTC)|Auipga}}<br />
<br />
:Yes, that's what I meant. If it does not work, it should be fixed rather than providing a duplicate instruction without a reason. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:16, 30 May 2021 (UTC)<br />
<br />
== Systemd-networkd systemd-networkd-wait-online.service discussion modifications ==<br />
<br />
I'm not sure why you're reverting my edits.<br />
<br />
You said: "''empty ExecStart is explained in Systemd#Examples''"<br />
<br />
Exactly: Systemd#Examples clearly states "''As another example, in order to replace the ExecStart directive for a unit that is '''not of type oneshot'''''"<br />
<br />
'''systemd-networkd-wait-online''' is a oneshot service. By having the superfluous empty ExecStart you're just confusing people.<br />
<br />
Regarding the file naming, yes the name is irrelevant, but it's generally helpful to non-expert users to stick to canonical naming conventions.<br />
<br />
Please make sure you're on solid ground before reverting edits; you're just discouraging people from engaging with the Wiki. Thanks. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 16:51, 9 June 2021 (UTC)<br />
<br />
:{{man|5|systemd.service}} says: "Unless Type= is oneshot, exactly one command must be given. When Type=oneshot is used, zero or more commands may be specified."<br />
:So when a service is not oneshot, users ''must'' clear ExecStart before adding a modified command in the drop-in file. If a service is oneshot, they ''may or may not'' clear ExecStart, since the service may have multiple ExecStart commands.<br />
:In case of systemd-networkd-wait-online, I don't see why you would want to run multiple instances with different options: one to wait for ''all'' links (which is the default command) and another one to wait for ''any'' link (which is the command in the drop-in example). So clearing ExecStart really makes sense for systemd-networkd-wait-online.<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:44, 9 June 2021 (UTC)<br />
<br />
== Pacman: Install missing dependencies ==<br />
<br />
Hi. [https://wiki.archlinux.org/index.php?title=Pacman&type=revision&diff=690774&oldid=690762 "Pacman" Revision as of 21:50, 4 August 2021 (undo)] - maybe at least put that into [[System_maintenance#Avoid_certain_pacman_commands]]?<br />
<br />
[[User:Galeksandrp|Galeksandrp]] ([[User talk:Galeksandrp|talk]])<br />
<br />
:[[System_maintenance#Avoid_certain_pacman_commands]] already mentions {{ic|-Rdd}}. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:12, 14 August 2021 (UTC)<br />
<br />
== DPMS: "\033[9;0]" ==<br />
<br />
Hi. It seems that you removed {{ic|echo -ne "\033[9;0]"}} from [[Display Power Management Signaling|DPMS]]<br />
<br />
https://wiki.archlinux.org/index.php?title=Display_Power_Management_Signaling&diff=629705&oldid=625073<br />
<br />
[https://www.denx.de/wiki/view/DULG/SwitchOffScreenSaverAndBlinkingCursor A DULG page] and [https://unix.stackexchange.com/a/23636 a U&L post] brought me here.<br />
<br />
May I ask (1) if this method is still working; and (2) where is this escape sequence documented? [not found in {{man|4|console_codes}}]<br />
<br />
Thanks.<br />
<br />
{{Unsigned|05:23, 15 August 2021 (UTC)|PXf}}<br />
<br />
:[[Display Power Management Signaling#DPMS interaction in a Linux console with setterm]] says that setterm works by writing escape codes to the terminal device. The first subsection shows how to reverse-engineer the escape codes. Note that the escape codes are an implementation detail that users should not be concerned with, their documentation is certainly not our job. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:40, 15 August 2021 (UTC)<br />
<br />
== Linux console/Keyboard configuration ==<br />
<br />
Hi, you recently reverted my edit https://wiki.archlinux.org/index.php?title=Linux_console/Keyboard_configuration&oldid=693887. The reason I made that edit, was that I used to put my custom keymap in {{ic|/usr/local/share/kbd/keymaps/personal}} per the previous version of the wiki page. But this doesn't work with ''sd-vconsole'', as it's include files don't get loaded. Your suggested workaround by adding all required files using [[mkinitcpio#BINARIES and FILES|mkinitcpio BINARIES and FILES]] is rather tedious, as all the include files need to be in there, added by hand. This is done automatically by ''sd-vconsole'' if the file was put in {{ic|/usr/share/kbd/keymaps/}}. The reason I made this edit is due to https://bugs.archlinux.org/task/71788. See Giancarlo Razzolini's comment. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:43, 2 September 2021 (UTC)<br />
<br />
:It's just one custom file under {{ic|/usr/local}} and one entry in {{ic|FILES}}. What is so tedious about it? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:37, 2 September 2021 (UTC)<br />
<br />
:: It's not just one file. All the dependencies need to be included too under {{ic|/usr/share/kbd/keymaps/}}. There are quite a few in my case, when I just include ''us.map'' to modify it slightly. See the ''sd-vconsole'' hook script. That script has a part where it finds all the dependencies of a keymap.<br />
<br />
:: * ''/usr/share/kbd/keymaps/i386/include/compose.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/euro1.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-keys-bare.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-with-alt-and-altgr.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/qwerty-layout.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/personal.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/us.map''<br />
:: * ''/usr/share/kbd/keymaps/include/compose.latin1''<br />
<br />
:: [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 12:01, 2 September 2021 (UTC)<br />
<br />
::: I moved this to the talk page so I remember it and others can discuss too. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:18, 4 September 2021 (UTC)<br />
<br />
::: Oh, I see. In that case I suggest we add a tip like this:<br />
::: {{Tip|If you use the {{ic|sd-vconsole}} [[mkinitcpio#Common hooks|mkinitcpio hook]] instead of {{ic|keymap}}, keymaps located under {{ic|/usr/local}} as well as their dependencies from {{ic|/usr/share/kbd/keymaps}} need to be manually specified in the {{ic|FILES}} array in {{ic|mkinitcpio.conf}}. On the other hand, custom files located in {{ic|/usr/share/kbd/keymaps}} will be added automatically when configured in {{ic|/etc/vconsole.conf}}.}}<br />
::: Because this is relevant only for people using the {{ic|sd-vconsole}} hook and otherwise it does not make sense to pollute {{ic|/usr/share/kbd/keymaps}} with custom files.<br />
::: — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:55, 5 September 2021 (UTC)<br />
<br />
== cow_* ==<br />
<br />
Hi Lahwaacz. About the [https://wiki.archlinux.org/index.php?title=Archiso&diff=next&oldid=692981 how/why issue] (there will be no more &lt;!-- --&gt;). What if, for once, that I want to install some large packages after booting archiso, and would not bother modifying packages.x86_64 and building again? [https://www.memesmonkey.com/topic/works+on+my+machine <s>''on my machine''</s>] Darren "Un1Gfn" "[[User:PXf|PXf]]" Ng ([[User talk:PXf|talk]]) 08:18, 12 October 2021 (UTC)<br />
<br />
:It is a subsection of "Tips and tricks", not "Troubleshooting", so it should start with a clear motivation saying ''why'' the tip is useful, rather than an error message that the user has no idea if they will face or not. If you have such description, feel free to rewrite the section. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 05:42, 13 October 2021 (UTC)<br />
<br />
::What about making it a subsection of "[[Archiso#Troubleshooting|Troubleshooting]]" and renaming it to {{ic|partition / too full}}? [[User:PXf|PXf]] ([[User talk:PXf|talk]]) 06:45, 13 October 2021 (UTC)<br />
<br />
:::It's better to motivate it as a tip/trick rather than solve the problem after it happens. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:48, 13 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
(Undo revision 699881 by Oliver (talk) - installing arch-install-scripts does not get the image to "the same footing" as the archiso, even installing something for the first time is not an excuse to violate Help:Style#Package management instructions)<br />
<br />
'the same footing' may be poor choice of wording maybe but it's also not false. You are in a SIMILAR place, not 'exactly identical to the dot' e.g. same footing<br />
<br />
but 'installing something for the first time' is NOT what is going on here really. If we quote the style guide:<br />
<br />
''every Arch user should know pacman's article by memory''<br />
<br />
<br />
The thing is, this is NOT an Arch user yet. They have no idea what's going on, how to do stuff and just want to get started and installed. You can't expect _new_ not-yet-a user, to figure out everything in a daunting installation; by being a smart-bum about it. Yes, the style guide is completely correct on all other points. But I would think that this is the exception, rather then the rule. Help your new users a little. Introduce them gentle with open arms. From a 'first UX kind of way, this is horrible to treat your potentially new users.<br />
<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 17:40, 26 October 2021 (UTC)</div>Oliverhttps://wiki.archlinux.org/index.php?title=User_talk:Lahwaacz&diff=700009User talk:Lahwaacz2021-10-26T17:40:56Z<p>Oliver: /* Install Arch Linux via Docker */ new section</p>
<hr />
<div>== bot checking links after move ==<br />
<br />
Hi, re [[Talk:Touchpad Synaptics#adding libinput alternative]]. [[Touchpad Synaptics]] has 100+ backlinks and the more important ones - a bit tedious task. I was just glancing over your clever github bot scripts. It would be handy to have a script after such moves: walk over the backlinks of [[Touchpad Synaptics]] and just replace "[[Touchpad Synaptics" with "[[Synaptics" from the links. That would leave all links to subsections intact. Leaving out the translations to handle manually, there would not be much to go wrong, or? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:36, 26 September 2015 (UTC)<br />
<br />
:Hi, thanks for the suggestion. It would be indeed handy in this case, but most likely not generally. Imagine that there was a [[UUID]] page, which was later generalized and renamed to [[Persistent block device naming]] and content about UUID is now only a section on the page. In this case using the naive replacement would likely change the meaning of many sentences, and using shorter redirects for convenience is actually encouraged. There would have to be a list of whitelisted "harmless" replacements, which could even help to replace <nowiki>[[pacman|Install]]</nowiki> with <nowiki>[[Install]]</nowiki> etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:01, 26 September 2015 (UTC)<br />
<br />
::Yes, good examples, but you are thinking universal already :) I did not mean it could be that. For example, if you take the time when the bulk of the title case moves were done. With such a script one could avoid a lot of internal redirects as well. E.g. [https://wiki.archlinux.org/index.php/Special:WhatLinksHere/Beginners'_Guide]. But it's ok, just an idea. Please close this, if you think it's too singular cases with a simple enough replacement where it could be applied. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:02, 26 September 2015 (UTC)<br />
<br />
== mkosi ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=Systemd-nspawn&diff=0&oldid=491975 revert]: You can use mkosi also to create a container/directory tree (-t directory). So it can do the same and more. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 11:33, 1 October 2017 (UTC)<br />
<br />
:Alright, how is the "more" relevant to systemd-nspawn though? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:30, 3 October 2017 (UTC)<br />
<br />
::Hi, mkosi let's you create images (or directory trees) of various different distributions and allows you to do things like setting the root-password or installing additional packages. systemd-nspawn alows you to boot such images/directory trees. So I thought mentioning mkosi as alternative to manually creating a container with pacstrap or debootstrap would be worth it. -- [[User:Nudin|Nudin]] ([[User talk:Nudin|talk]]) 22:23, 5 October 2017 (UTC)<br />
<br />
== Waking from suspend with USB device ==<br />
<br />
Hi Lahwaacz, thanks for your input on this topic.<br />
Can you help me a bit further, I know the USB host controller and the USB device are different things but I thought that enabling the host controller was not necessary anymore, see [https://www.spinics.net/lists/linux-usb/msg53661.html].<br />
In my case all the {{ic|driver/*/power/wakeup}} are all enabled by default and the {{ic|/proc/acpi/wakeup}} as well.<br />
Anyway I have added a step in my explanations to identify the path awaiting for more clarity.<br />
<br />
[[User:Kewl|Kewl]] ([[User talk:Kewl|talk]]) 21:57, 16 January 2018 (UTC)<br />
<br />
:Hi, thanks for the link, it's entirely possible that something changed since the section was written. However, in my case only the keyboard device has wakeup enabled by default: {{bc|<nowiki><br />
$ for f in /sys/bus/usb/drivers/usb/*/power/wakeup; do echo "$f: $(cat $f)"; done<br />
/sys/bus/usb/drivers/usb/1-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/2-1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-11/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/3-12/power/wakeup: enabled<br />
/sys/bus/usb/drivers/usb/3-13/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/4-4/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb1/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb2/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb3/power/wakeup: disabled<br />
/sys/bus/usb/drivers/usb/usb4/power/wakeup: disabled<br />
</nowiki>}}<br />
:But in practice it seems to wake up the system even without the host controllers enabled for wakeup... It might also depend on some BIOS/firmware settings but if it works by default on most systems then I think the host controller settings could be removed again.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:14, 19 January 2018 (UTC)<br />
<br />
== Are supported local/remote destinations important for choosing a backup program? ==<br />
<br />
You [[Special:Diff/525550|reverted]] my edit adding supported backup destinations to [[Synchronization_and_backup_programs]]. This is puzzling to me. Here are some thoughts:<br />
* if choosing any backup program, the ability to send the backup off-site vs only on a local disk is a key feature consideration. Perhaps *the* key feature: one helps me recover in case my house gets burglarized or burns down, and the other does not. This is a much more important feature consideration than, say, whether the program is written in Go or Mono (something that has a full column). I think it's hard to disagree on that.<br />
* Given this, I am very puzzled you would use the term "useless" in the revert message.<br />
* I assume you didn't like that the table got even bigger (it didn't fit into the layout even before). I don't like it either, but perhaps the revert should have said "can you put this somewhere else, not in this already-too-big table?"<br />
* On a personal note, when I provide feedback or give opinion on somebody else's work, I'd like to be constructive and kind, instead of aggressive and putting people down. Just a thought. Thanks for listening.<br />
<br />
[[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 17:38, 11 June 2018 (UTC)<br />
<br />
:No because you can use any remote back-end with any backup application by just running one command / writing the backups to a [[FUSE]] (if available).--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 04:39, 12 June 2018 (UTC)<br />
<br />
::Hmm, by that reasoning we don't need the Arch package repository, as long as we have source code and makepkg. Or Perl, if we have bash and awk. But even then, and if all the fuse backends existed (I doubt they do), and if it were easy to set all of them up (another thing I doubt), do you indeed believe that running something written to read/write local files will be just as efficient backing up gigabytes of data to a remote repository as something that is specifically optimized for that use case? Note that backing up, say, daily, a typical hard drive via tpyical consumer broadband is still quite a bandwidth challenge in many places today. What about we add this info, and remove (or merge) some other columns to make the table smaller? {{Unsigned|18:08, 12 June 2018|Jernst}}<br />
<br />
:::Your comparisons don't make sense. Mind the slash in my response, you do not need a FUSE implementation, a simple CLI suffices. You do not need to "set all of them up", you only need one. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 18:47, 12 June 2018 (UTC)<br />
<br />
::::If you ever attempt to help a normal user set up a reliably-working off-site backup strategy, think of this discussion. In the meantime, this is all the time I'm going to spend on a discussion that has such repeated gems in it as "makes no sense" without explaining why you think so. Have a nice day. [[User:Jernst|Jernst]] ([[User talk:Jernst|talk]]) 18:54, 12 June 2018 (UTC)<br />
<br />
== The pip section in [[Python package guidelines]] ==<br />
<br />
Hi, you wanted the warning about using pip or wheels restored but accidentally(?) reverted my whole set of changes. I redid them, leaving the warning in place. – [[User:Flying sheep|flying sheep]] 08:17, 8 March 2019 (UTC)<br />
<br />
:Full revert was intentional, because the "wheel" section is not a full replacement for "pip" because there are packages which don't provide wheel files. As I said in the edit summary, there is no reason to recommend one or the other due to the warning. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:21, 8 March 2019 (UTC)<br />
::That still doesn’t explain why you reverted the first part, that had nothing to do with the pip/wheel section and simple improves the files.pythonhosted.org URLs. I restored that one while we’re discussing the pip/wheel section. And about that: There’s no reason to use pip for anything else, and pip is only used because some people (me included) didn’t understand that you can install most wheels by just extracting them to the correct location. So what do you think is missing from my wheels section that the former pip section had? – [[User:Flying_sheep|flying sheep]] 11:41, 11 March 2019 (UTC)<br />
<br />
:::If you didn't notice, the page includes "guidelines" in the title. So the page should contain only common and recommended ways to do things, not everything that is possible to do. If you think that your way to install "wheels" should be followed by everybody, feel free to discuss it on the talk page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:26, 11 March 2019 (UTC)<br />
::::Well, extracting static archives sounds much more recommended than running pip with like 7 options to make it behave. I added a talk item: [[Talk:Python package guidelines#Remove_pip_section_in_favor_of_wheels_section?]] – [[User:Flying_sheep|flying sheep]]<br />
<br />
== wpa_supplicant ==<br />
<br />
Regarding https://wiki.archlinux.org/index.php?title=WPA_supplicant&diff=577215&oldid=577167, one person ran into this problem in March of this year and spent too much time diagnosing it:<br />
<br />
https://bbs.archlinux.org/viewtopic.php?id=244950<br />
<br />
It took me a few days to find the problem. I want to make sure the next time someone encounters it, they easily find relevant information about what the cause is. Since you've reverted my edits to both netctl and wpa_supplicant, what do you suggest?<br />
<br />
--<br />
<br />
[[User:Pooryorick|Pooryorick]] ([[User talk:Pooryorick|talk]]) 08:24, 18 July 2019 (UTC)<br />
<br />
== F2FS and GRUB ==<br />
<br />
Hello. :) I'm here to address a recent disagreement. I noticed a reversion of my edit regarding the F2FS filesystem, in particular regarding the configuration file to edit (with you representing /boot/grub/grub.cfg and me representing /etc/default/grub). I run F2FS on my daily driver with an encrypted root filesystem and encrypted boot on a separate partition, and have never had to touch grub.cfg. I only automatically generate it. It's possible to use either, but /etc/default/grub would make more sense as a recommendation in my mind because grub.cfg has the potential to be overwritten during updates, whereas /etc/default/grub doesn't. <br />
<br />
If there's a compelling reason to use grub.cfg over /etc/default/grub, please let me know. ^^ I'm always eager to learn more about Arch. I don't want to get in a reversion war so I've left your change untouched for the time being.<br />
<br />
[[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 00:17, 8 September 2019 (UTC)<br />
<br />
:The reason is explained in the section: "If GRUB is used with an unsupported filesystem it is not able to extract the UUID of your drive so it uses classic non-persistent /dev/sdXx names instead." If it does not apply to F2FS, it should be made clear. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:29, 8 September 2019 (UTC)<br />
<br />
::You can specify UUID's in GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, so my proposed solution would work for F2FS and other unsupported filesystems, without the burden of manually editing grub.cfg. If there's anything I need to clarify or something else I'm missing, just let me know. :) [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 19:37, 8 September 2019 (UTC)<br />
<br />
:::The {{ic|1=root=}} parameter is not supposed to be in GRUB_CMDLINE_LINUX_DEFAULT, regardless if UUID is used or not. ''grub-mkconfig'' automatically detects the root filesystem and adds the appropriate {{ic|1=root=}} parameter based on GRUB_DISABLE_LINUX_UUID. In any case, your change to the paragraph does not make sense. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:02, 8 September 2019 (UTC)<br />
<br />
::::It could simply be because I use full disk encryption, and adding a kernel parameter for the encrypted disk's UUID is correct in that situation. You're more experienced with contributing to the wiki, so I guess I'll defer to your judgment. It felt like a reasonable edit and solution to me and I don't see the downside to including it in GRUB_CMDLINE_LINUX_DEFAULT. [[User:Eurydice|Eurydice]] ([[User talk:Eurydice|talk]]) 05:38, 9 September 2019 (UTC)<br />
<br />
== dracut executable link ==<br />
<br />
Hello, your last edit on the dracut page (https://wiki.archlinux.org/index.php?title=Dracut&oldid=596388) that undid my 'Link to direct "make executable" section for executable link' commit states: "the redirect executable points exactly to that section", but it doesn't. Following the [[executable]] link just points to the top of the Help:Reading page.<br />
<br />
{{unsigned|17:06, 28 January 2020|Krathalan}}<br />
<br />
:In that case your browser probably does not work correctly, because the redirect [https://wiki.archlinux.org/index.php?title=Executable&redirect=no really points to the section]. Or MediaWiki, there was a bug several years ago... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:41, 28 January 2020 (UTC)<br />
<br />
:: How strange... thanks for pointing that out. It does indeed appear to be some issue with my Firefox configuration. [[User:Krathalan|Krathalan]] ([[User talk:Krathalan|talk]]) 19:51, 28 January 2020 (UTC)<br />
<br />
== Getting install.php work in DokuWiki ==<br />
<br />
Hi, than you for having undone my contribution and pointed to the right solution on [[Dokuwiki#Configuration]]. Indeed I had read this solution before, but I was misled by the condition "if you are using lighttpd or nginx and your PHP version is lower than 7": as I use Apache with php v. 7.4.3 I didn't take it into account. Do you know what a correct rephrasing could be? Maybe it should be deleted?<br />
<br />
Also, I think that, at the end of this same section, one should add something like "verify that {{Pkg|php-gd}} is installed and restart {{ic|php-fpm.service}}".<br />
<br />
Naturally I can do it myself, but I prefer to ask before.<br />
[[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 17:31, 19 February 2020 (UTC)<br />
<br />
:Hi, apparently it depends on whether you had {{ic|open_basedir}} set previously or not. I've changed the page, feel free to update the gd extension. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:16, 19 February 2020 (UTC)<br />
<br />
::Thank you! However, while, I didn't have {{ic|open_basedir}} set previously, I couldn't access ''install.php''. I suspect there is another thing to do, since the configuration editor in DokuWiki complains that it cannot modify the configuration files although ownership and permissions are correctly set for the relevant symlinks, directories and files, and so is {{ic|open_basedir}}. However I can edit my pages. Maybe a return from a new user with a fresh installation would be more useful, though. [[User:BDumont|BDumont]] ([[User talk:BDumont|talk]]) 08:20, 20 February 2020 (UTC)<br />
<br />
== Dead link in Simple stateful firewall#See Also ==<br />
<br />
Hi, Jakub. I am about [https://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&diff=599725&oldid=599717 this] edit. I tried to follow that link one more time and it is not require entering captcha. I am not see any content limitations and my colleague (he uses Tor) does not see them too. I am not sure how it works, so I leave it on your descision. -- [[User:Duodai|Duodai]] ([[User talk:Duodai|talk]]) 14:29, 1 March 2020 (UTC)<br />
<br />
:Well, maybe it depends on the location from which the request comes. But I don't know how it works either... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:33, 1 March 2020 (UTC)<br />
<br />
::my guess is it returns captcha for crawlers only -- [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 01:59, 2 March 2020 (UTC)<br />
<br />
:::I'm getting it in my browser... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:14, 2 March 2020 (UTC)<br />
<br />
== SystemD user units depending on graphical session ==<br />
Hi,<br />
regarding reverting my addition to [[Systemd/User]], could you please explain why? I referenced [[https://www.freedesktop.org/software/systemd/man/systemd.special.html]] which directly contradicts what you said in your summary.<br />
<br />
{{unsigned|19:53, 5 May 2020|Fuero}}<br />
<br />
:The note in [[Systemd/User#How it works]] still applies - systemd services are never per-session, but per-user. The service does not magically get the correct DISPLAY or WAYLAND_DISPLAY variable, it does not work if you have multiple sessions per user, etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:45, 6 May 2020 (UTC)<br />
<br />
== Plymouth ==<br />
<br />
Actually with just Plymouth it does not work properly. Even 0dd17y had the same issue in https://bbs.archlinux.org/viewtopic.php?id=220900.<br />
<br />
The reason I did not file a bug report is that it is anyway fixed in the git version and the latest release (0.9.4) is around 2 years behind master<br />
<br />
{{unsigned|09:50, 6 May 2020|M.Srikanth}}<br />
<br />
:So if you don't have to file a bug report, add a full troubleshooting entry or at least properly reference your inline note instead of resorting to plain "if that does not work, try this instead". -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:15, 6 May 2020 (UTC)<br />
<br />
== [Bitcoin core] build the code and run the test suites ==<br />
<br />
Hello,<br />
<br />
This week, I managed to build the Bitcoin code and run all the test suites with the help of this page: https://jonatack.github.io/articles/how-to-compile-bitcoin-core-and-run-the-tests<br />
<br />
Archlinux has two particularities:<br />
* being in rolling release, it takes to manually use the library {{ic|Berkeley DB (BDB) v4.8}}<br />
* the {{ic|/tmp}} directory is by default limited to half the size of the Ram<br />
<br />
For these reason, maybe it could be interesting to have a page in the wiki to explain how to build the Bitcoin core?<br />
<br />
Cheers,<br />
<br />
Thomas<br />
<br />
[[User:Thomasb|Thomasb]] ([[User talk:Thomasb|talk]]) 20:29, 9 May 2020 (UTC)<br />
<br />
:I don't think that this is useful. There is the {{AUR|bitcoin-core-git}} package and nothing more should be needed. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:53, 26 May 2020 (UTC)<br />
<br />
== Double linefeed results in extra line ==<br />
<br />
If you look at templates that end with double linefeed before noinclude this would result in extra line in resulting page.<br />
<br />
It may be a minor point but since you are perfectionist about wikitext I should mention this is a tradeoff and it results in slightly worse result.<br />
<br />
Removing just one linefeed removes the problem while still allowing it to not jumble all the tags into same line.<br />
<br />
-- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 16:30, 11 May 2020 (UTC)<br />
<br />
:If this is about [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=next&oldid=612179], the spaces I added back are not included when the template is used elsewhere, because the spaces are inside the noinclude tags. The extra space is only on the template page itself, but it does not result from template inclusion. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:41, 11 May 2020 (UTC)<br />
<br />
::OFC, I mean the template page render has extra line. -- [[User:Svito|Svito]] ([[User talk:Svito|talk]]) 21:21, 11 May 2020 (UTC)<br />
<br />
:::I agree with [[User:Svito|Svito]], isn't it good to delete the extra blank lines? -- [[User:Blackteahamburger|Blackteahamburger]] ([[User talk:Blackteahamburger|talk]]) 05:39, 12 May 2020 (UTC)<br />
<br />
::::OK, let's do it. [https://wiki.archlinux.org/index.php?title=Template:Cat_main&diff=616382&oldid=612181] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:47, 26 May 2020 (UTC)<br />
<br />
== Re: lighttpd: remove python2 version ==<br />
<br />
Instead of removing the example we could as well add an example using a Python3 library like https://pypi.org/project/flup6/.<br />
<br />
{{unsigned|15:23, 18 May 2020|Gruentee}}<br />
<br />
:Feel free to add it if you find it useful. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:56, 18 May 2020 (UTC)<br />
<br />
== Xbindkeys removal ==<br />
<br />
Hi, just wondering why you [https://wiki.archlinux.org/index.php?title=Xbindkeys&diff=617675&oldid=617670 removed my edit] from [[Xbindkeys]]? The xbindkeys page has a number of quick tips but no mention of how to bind anything to the Print Screen key so I thought it would be useful to add. -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 02:27, 3 June 2020 (UTC)<br />
<br />
:Giving examples for all keys on the keyboard is useless, there is [[Xbindkeys#Identifying keycodes]] which teaches how to find the keycodes and keysyms of any key. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 3 June 2020 (UTC)<br />
<br />
:: So how come you left the examples for the volume up/down and brightness? What is different between those examples and a screenshot example? Aren't more examples better to save people from hunting all over the place trying to piece things together themselves? -- [[User:Malvineous|Malvineous]] ([[User talk:Malvineous|talk]]) 14:03, 4 June 2020 (UTC)<br />
<br />
:::The difference is that when it comes to volume control, there are 1 or 2 options for the 99% most common cases, but for screenshot taking there are dozens of different options. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:15, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for edit to XDG Base Directory page regarding python_history ==<br />
<br />
I understand the justification for reverting the change I made, however I would like to point out that similar entries on the page (such as Maven) also have instructions for what contents to put in files (even though there is native documentation for those settings). Additionally, it took me a bit of re-reading on the linked Python documentation to reason out how the documentation's example needed to be modified, since it's not clear from the Python documentation whether placing such code in the PYTHONSTARTUP file will actually ''override'' the default behavior. [[User:Varriount|Varriount]] ([[User talk:Varriount|talk]]) 20:44, 20 June 2020 (UTC)<br />
<br />
:Even maven's note can be [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&diff=631704&oldid=631630 shortened]. The notes in the table must be as short as possible, there is no place for extended explanations or long code snippets like in the upstream documentation. If the Python's documentation is not clear enough, I don't think any note in a massive convoluted table will ever be better. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:47, 12 August 2020 (UTC)<br />
<br />
== Re: Revert for Backlight page ==<br />
<br />
Hi, you reverted my change to [[Backlight]] page that mentioned WIP patches for controlling OLED panel brightness. I don't really understand justification for reverting it since currently the page says that OLED brightness can be controlled only by changing gamma ramp. That is wrong - since it's not the only way - these panels can control brightness with a PWM. Moreover controlling brightness with gamma ramp is not optimal - it essentially reduces dynamic range, i.e. at 50% you have 7 bits per pixel, at 25% - 6 bit per pixel, etc. That results in banding artifacts at lower brightness level.<br />
<br />
As far waiting for the patches to be merged before mentioning it there - it'll take ~3-6 months (yes, that's the process) and I haven't found *any* reference to these changes on the internet - everyone recommends using gamma ramp instead of fixing it properly. I'm absolutely sure that having information about these patches would not hurt [[User:Anarsoul|Anarsoul]] ([[User talk:Anarsoul|talk]]) 15:56, 30 June 2020 (UTC)<br />
<br />
:Linking to a repo which which has 2 custom commits on top of some arbitrary development version of the Linux kernel tree is not helpful for users. Nobody will compile directly from this repo which is already significantly outdated compared to recent kernel versions and there is no indication if the patches actually work with newer (or older) kernels. We can mention the PWM control as a general concept though. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:32, 12 August 2020 (UTC)<br />
<br />
== Automatic template correction ==<br />
<br />
Per [[Help:Template#Style]], templates should be used with the capitalization shown in the examples in their pages, so {{ic|&#123;{AUR&#124;...}} is correct, while {{ic|&#123;{aur&#124;...}} is not.<br />
<br />
However, there are pages that don't respect that rule (e.g. [[Android_Debug_Bridge]] until recently).<br />
<br />
I beleive this correction should be easy to implement using a bot. What do you think?<br />
<br />
{{unsigned|07:24, 25 August 2020|Relrel}}<br />
<br />
:Yes, this should be easy, but the bot should not make a huge amount of simple style-only changes - they should be combined with corrections for more complex rules. Anyway, there is an idea to create a [https://github.com/lahwaacz/wiki-scripts/issues/22 style linter] for the ArchWiki rules. Would you like to help? ;-) – [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:21, 25 August 2020 (UTC)<br />
<br />
== Failed to create tun device ==<br />
<br />
I don't understand your reason for [[https://wiki.archlinux.org/index.php?title=NetworkManager&diff=0&oldid=634880 removing my section in NetworkManager]]. Could you elaborate?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 07:40, 11 September 2020 (UTC)<br />
<br />
:You can't use [[systemd-networkd]] and [[NetworkManager]] at the same time. Even if you don't have any ''.network'' file for systemd-networkd, you can't solve NetworkManager's problems with systemd-networkd. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:43, 11 September 2020 (UTC)<br />
<br />
::Ok, thanks, in this case it solved the error I got. Now the VPN works. Do you have an idea about how to solve it without systemd-networkd?--[[User:Egils|Egils]] ([[User talk:Egils|talk]]) 22:27, 11 September 2020 (UTC)<br />
<br />
:::You should really fix the permission problem for {{Pkg|networkmanager-openvpn}}. The tun interface should be managed by OpenVPN which needs rights to create it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:37, 12 September 2020 (UTC)<br />
<br />
::I don't think this statement is entirely correct. [[systemd-networkd]] and [[NetworkManager]] can happily co-exist together if they are managing different interfaces. I unfortunately don't have a reference to point to this, but I came across this being mentioned a couple of times on forums. I personally use [[NetworkManager]] on my laptop to handle wifi, while [[systemd-networkd]] is in control of virtual ethernet and bridges for all my [[systemd-nspawn]] instances. [[User:Romstor|Romstor]] ([[User talk:Romstor|talk]]) 03:24, 12 September 2020 (UTC)<br />
<br />
== [https://wiki.archlinux.org/index.php?title=XDG_Base_Directory&oldid=636526/ XDG Base Directory]: Undo revision 636525 ==<br />
<br />
Dear Lahwaacz,<br />
<br />
maybe my changes were to rushed and from my point of view only. But I have two points to consider:<br />
<br />
# If I put the quotes around my vimrc and source it from my .bash_profile, I get the vim-error E471 (Argument required). Without quotes, this doesn't happen. So this change based on experience.<br />
# The rtp should includes directories, which are needed at runtime. (in plain vim e.g. ~/.vim). This is not a typical configuration directory. My mistake was, that I supposed that everyone put their vim plug-ins in $XDG_DATA_HOME and not in $XDG_CONFIG_HOME, because from my point of view a plug-in doesn't belong to the configuration. Maybe it is a good idea to add a remark, which explains the addition of $XDG_CONFIG_HOME to the rtp.<br />
<br />
[[User:Grrr|Grrr]] ([[User talk:Grrr|talk]]) 13:53, 26 September 2020 (UTC)<br />
<br />
# Quotes are there because $XDG_CONFIG_HOME may contain spaces.<br />
# It's not only about quotes - the runtimepath has subdirectories for color schemes, keymaps, autoload scripts etc.<br />
-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 26 September 2020 (UTC)<br />
<br />
== Readability in Wiki ==<br />
<br />
I noticed that you and the other admins and moderators often want sentences to continue endlessly, without line breaks.<br />
For example in the introduction of [[Wayland]].<br />
<br />
I think it would be better to have more seperated sentences, so it is easier to read and "important" information is easier visible for people.<br />
I don't know who is responsible, but maybe some options in MediaWiki (or whatever this wiki software is) could be changed as well, to make make line breaks etc. easier and reduce the height-space (if you know what I mean) between sentences, so it looks better, even though line breaks are used.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:38, 15 October 2020 (UTC) G3ro<br />
<br />
:I don't know exactly what you mean. Is it about the readability of the rendered HTML or the "source code" of the page? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:15, 15 October 2020 (UTC)<br />
<br />
:: Well I guess it can be about both. But mainly it is about what people see on the page.<br />
:: There are three seperate topics I mentioned:<br />
<br />
:: 1. Use line breaks: I would like to use more line breaks, because if you have long sentences that are written after each other without line breaks, it gets "harder" to recognize when the next sentence starts.<br />
:: While I agree to what you said somewhere, that sentences that belong directly together, should be written in one "paragraph", it would be useful for sentences that cover (slightly) different "topics" to be visibly parted.<br />
<br />
:: 2. Adjust margin options: I notice that when line breaks are used, there is a vertical space added between two sentences. Just like in this post. If you would use line breaks more often, this is a little too much spacing in my oppinion.<br />
<br />
:: 3. Potential options to make line breaks easier: It would be very convenient if a line break in the source code would lead to a line break in displayed text as well, instead of needing to add an empty line.<br />
<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:33, 15 October 2020 (UTC) G3ro<br />
<br />
:::OK, now I understand. I agree that splitting different topics usually improves legibility, but they should be split into separate paragraphs and not just by line breaks (e.g. using the &lt;br> tags). Paragraphs are semantic units whereas line breaks inside a paragraph are usually typographic errors.<br />
:::Also note that such splitting alone may not be enough to improve the text flow. For example, if we consider the intro for [[Wayland]], the second sentence about XWayland would not constitute a good paragraph - it is just a plain statement and the new topic is not nicely introduced. Ideally, you'd split the topic and make some wording changes for the second paragraph.<br />
:::As for the margin options, that is the difference between paragraph splitting and non-semantic line breaks. In my opinion, the styling is correct in this respect, as paragraphs should be discernible. You mentioned that you like line breaks to easily recognize where a sentence ends - but reading should be based on whole paragraphs, not sentences. There should be no reason to skip anything in the middle of a paragraph, otherwise it should be probably split into multiple paragraphs or otherwise rephrased.<br />
:::If you find it hard to follow a long sentence horizontally on a wide screen, we might consider enforcing some maximum width for the whole content. I think the readability would be better, since there would be more top-to-bottom eye movement at the cost of left-to-right-and-back.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:59, 15 October 2020 (UTC)<br />
<br />
== Xorg parentheses ==<br />
<br />
I actually think that X(org) is very useful to imply that it is one and the same thing.<br />
<br />
It might even be more confusing now, as we use both Xorg and X, because the wiki title and the package titles are Xorg.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:30, 17 October 2020 (UTC) G3ro<br />
<br />
:Well the conventions should be established on the [[Xorg]] page, not anywhere else... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:36, 17 October 2020 (UTC)<br />
<br />
:: Imo the conventions are established by upstream and they use a wide variety of X, X.org, X(org), Xorg etc.<br />
:: As I said I always prefer X(org) because then it is clear, that both are same thing.<br />
:: But ultimately it's your decision. <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 13:43, 17 October 2020 (UTC) G3ro<br />
<br />
:::When upstream is not capable of making a unambiguous decision, it makes sense that other projects pick some option and stick with it wherever they can to keep at least some consistency. So for this wiki, pages should use the same style as the [[Xorg]] page. But feel free to start a discussion about this in [[Talk:Xorg]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:56, 17 October 2020 (UTC)<br />
<br />
== SSHFS - systemd edit ==<br />
<br />
The edit was removed because "there is no advantage over using fstab entries".<br />
<br />
Is not only about the dis/advantages of the systemd option, is about that it is another possibility to achieve the task, that is why it was created in another level and the fstab section was left alone.<br />
<br />
Reconsider the edit as it presents another option which people can use.<br />
<br />
[[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 16:22, 22 October 2020 (UTC)<br />
<br />
:There is no need to use anything else, fstab just works well enough. Configuring mounts with systemd services is not a good idea - it is much more bloated than fstab and not the right tool for it. If anything, a different type of systemd units should be used: {{man|5|systemd.mount}}. But creating the mount units manually is still pretty useless since everything can be configured in fstab and systemd will generate the unit for you. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:22, 22 October 2020 (UTC)<br />
<br />
:: It is about the ability to use the user's .config file and all the proper options that are saved there. Also systemd gives the possibility to use different targets, so the user could mount it when an specific user logs in or when a graphical session starts. I could argue that bad a modification of fstab could lead to a system that doesnt boot, but such poorly configured systemd unit file just fails and the system is fine. Just give the user the information and let it decide what they can use depending on their use case. [[User:Garnica|Garnica]] ([[User talk:Garnica|talk]]) 08:08, 24 October 2020 (UTC)<br />
<br />
:::You can configure systemd targets in fstab using the {{ic|x-systemd.wanted-by}} and {{ic|x-systemd.required-by}} options, there are also {{ic|nofail}} and {{ic|noauto}} options. Please read the {{man|5|systemd.mount}} manual.<br />
:::Using hosts from the user's {{ic|.ssh/config}} is the only thing which is not possible with fstab, but this does not warrant using the wrong tool for the task. Simple copy the full {{ic|user@hostname}} into fstab and you're done.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:47, 24 October 2020 (UTC)<br />
<br />
== [[Self-encrypting drives]] ==<br />
<br />
Hi, I'd like to respectfully disagree with the rollback. It's specific to sedutil that with most commands you need to input /dev/nvme0 (when encrypting the device) but for the sleep commands it requires /dev/nvme0n1 or it fails with a very unspecific error (Error saving the password to the kernel errno = 25), as found out in the discussion https://github.com/Drive-Trust-Alliance/sedutil/issues/90<br />
<br />
All in all I believe that it is important to keep this piece of information which was found out in a long discussion between the reporter and the developers. I ran into it and I believe many people may run into it, considering most of the new SSD will be NVMe. Best, [[User:Przemub|Przemub]] ([[User talk:Przemub|talk]]) 13:34, 28 October 2020 (UTC)<br />
<br />
:OK, then it makes sense. But it should be probably explained before, not in the section about the sleep command. Also please add the link to the note as a reference. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:27, 28 October 2020 (UTC)<br />
<br />
== Nvidia Installation ==<br />
<br />
The whole guide is unnecessary long and overcomplicated formulated.<br />
Shorter is better, most people will know their graphic card for example, so the determination etc. is only optional.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:21, 10 November 2020 (UTC) G3ro<br />
<br />
:Moving some info to some other page and leaving a tip behind does not make it shorter, but harder to follow. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:36, 10 November 2020 (UTC)<br />
<br />
== Btrfs layout ==<br />
<br />
Hi, Lahwaacz<br />
<br />
Thanks for maintaining [[Snapper]]! However I think the layout is not openSUSE specific and beneficial to all btrfs users. Can you elaborate your reason of undoing the edits? IMO the previous 'simple layout' complicates the rollback procedure.<br />
<br />
Cheers,<br />
[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 07:26, 3 December 2020 (UTC)<br />
<br />
:It is not overcomplicated, it is just doing things right. You can read about that in the forum thread, see the first note in [[Snapper#Suggested filesystem layout]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:24, 3 December 2020 (UTC)<br />
<br />
::Anyway I've moved the guides to my user page. It's not that I haven't read the 5-year-old forum post, it's that before the current layout I followed that post and resulted in a not fully rolled-back system. That post also sourced (then current) information from openSUSE. openSUSE has since massively overhauled the layout, as I pointed out in an edit you undid earlier.[[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 09:02, 3 December 2020 (UTC)<br />
<br />
::Since last message I've extensively documented the new layout at [[User:I2Oc9/Btrfs_subvolumes]] and [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption]]. Have a look for yourself. Nothing new really, but IMO [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my take]] is much more simpler and complete than the supposedly [[Snapper#Restoring_/_to_a_previous_snapshot_of_@|simpler one]]. That one does not leverage native {{ic|snapper rollback}} or {{Pkg|grub-btrfs}}, among other things. I strongly suggest you try if you have time. [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 11:55, 3 December 2020 (UTC)<br />
<br />
::Actually if you look closely, none of [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Rollback_/_&_system_recovery|my recovery methods]] is specific to [[User:I2Oc9/Btrfs_subvolumes#A_new_kind_of_layout|the new 'complex' layout]], it will work totally fine with the old one. I just don't think moving @ around in live environment is appropriate.<br />
<br />
::On the other hand, the layout recommendation has been updated by openSUSE [https://en.opensuse.org/SDB:BTRFS], why stick with the old one? [[User:I2Oc9|I2Oc9]] ([[User talk:I2Oc9|talk]]) 12:37, 3 December 2020 (UTC)<br />
<br />
:::The main reasons why I reverted your edits on the [[Snapper]] page are: 1) it was a huge change which was not discussed previously as required by [[ArchWiki:Contributing#The 3 fundamental rules]], and 2) it has some elements which do not apply to Arch (see below). If you wish to propose a better layout of the subvolumes, it should be discussed in [[Talk:Snapper]] first. Your user pages would serve as great drafts.<br />
:::Note that the current suggested layout is not ''flat'' in the sense of [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|your section]] - it has a separate subvolume for {{ic|.snapshots}} so it does not lead to the recursive mess. So your proposed layout seemed very similar to the current suggested layout. The real difference is which subvolume gets mounted at {{ic|/}}, but I did not find it explained anywhere on the Snapper page before I reverted the changes (I get it now from your user page). I also did not find a proper documentation of the openSUSE's layout - it seems to be just the product of their installer and the documentation only deals with the result, saying at most that [https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-snapper.html#sec-snapper-snapshot-boot the subvolume configuration must not be changed] for rollbacks to work.<br />
:::Now the openSUSE-specific elements: some Arch packages actually install software into {{ic|/opt}}, so the recommended layout should not suggest a separate subvolume for this path. Even more importantly, the pacman database is located at {{ic|/var/lib/pacman/local/}} and it must be rolled back along with the system, so there should be no separate subvolume for {{ic|/var}}. Instead, users should be encouraged to create (even nested) subvolumes for specific data directories under {{ic|/var}}, such as {{ic|/var/log}}, {{ic|/var/tmp}}, {{ic|/var/cache/pacman}}, {{ic|/var/lib/machines}}, etc.<br />
:::Finally, the suggested layout should not be GRUB-specific, there should be no recommendations regarding a boot loader. Sure it is useful to include non-trivial tips, but people may actually use a different boot loader.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:31, 4 December 2020 (UTC)<br />
<br />
::::Thanks for your detailed reply. I admit that I'm not knowledgeable on the intricate differences between distributions and shouldn't have made the changes without properly discussing them first.<br />
::::Yes, I get that the current layout is not [[User:I2Oc9/Btrfs subvolumes#Snapper on flatly-installed system subvolume|the one described in this section]] and indeed properly separates {{ic|/.snapshot}} and {{ic|/}}. The layout I proposed attempts to add some "niceties" such as supporting multi-distribution installations (complex and unnecessary, I agree) and bring the openSUSE layout here, which is a mistake, as you've pointed out.<br />
::::As for GRUB, since I use LUKS all the time and it's the only bootloader supporting encrypted {{ic|/boot}} on Btrfs on LUKS1, I really didn't think of any other possibilities.<br />
::::I will incorporate your recommendations to my user page and add a new section in [[Talk:Snapper]] pointing to those pages.<br />
::::Cheers -- [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:09, 4 December 2020 (UTC)<br />
<br />
:::::I've adopted [[Install_Arch_Linux_on_ZFS#System_datasets|Archlinux Root on ZFS layout]] to [[User:I2Oc9/Root_on_Btrfs_with_LUKS_full_disk_encryption#Create_subvolumes|my proposal]]. [[User:S0x9v|S0x9v]] ([[User talk:S0x9v|talk]]) 10:56, 4 December 2020 (UTC)<br />
<br />
== Reflector Revert ==<br />
<br />
Hi Lahwaacz, about your [https://wiki.archlinux.org/index.php?title=Reflector&oldid=643749 revert], it seems like there's precedence for including AUR packages that replicate the code on the wiki. For example, in [[dash#Relinking /bin/sh]].<br />
<br />
In addition, I believe that there's value for linking the AUR package because it allows a simpler user experience where the AUR package is maintained for them. That way, if it is ever updated, they can easily fetch the update instead of religiously checking the wiki page (which most users probably don't do).<br />
<br />
Thanks!<br />
<br />
[[User:Denton-l|Denton-l]] ([[User talk:Denton-l|talk]]) 01:52, 7 December 2020 (UTC)<br />
<br />
:That precedence was only created by [https://wiki.archlinux.org/index.php?title=Dash&type=revision&diff=561587&oldid=518398 yourself]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 5 May 2021 (UTC)<br />
<br />
== firefox zoom ==<br />
<br />
"no reason to zoom manually, see HiDPI)" - fractional scaling doesn't work [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 02:38, 26 December 2020 (UTC)<br />
<br />
:That should be explained in [[HiDPI#Firefox]] anyway. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:48, 26 December 2020 (UTC)<br />
<br />
::it's good to have this mentioned somewhere clearly so people know about it before they say "fonts on linux suck" [[User:Ubone|Ubone]] ([[User talk:Ubone|talk]]) 15:51, 29 December 2020 (UTC)<br />
<br />
== Intel GVT-g edits ==<br />
<br />
Hello Lahwaacz,<br />
<br />
I have noticed that you reverted one of the edits I have performed on [[Intel_GVT-g]].<br />
<br />
About this revert: [https://wiki.archlinux.org/index.php?title=Intel_GVT-g&oldid=648062 Windows problems are out of scope]<br />
<br />
While I understand that the ArchWiki is about ArchLinux, this article in particular mentions Windows in the introduction, and already includes another troubleshooting point about Windows. The issue I have encountered with the black bars is somewhat common, as I have found other people discussing it online, and I really fail to see why not including this piece of information in this article would be better than including it.<br />
<br />
Please, let me know your thoughts. If you think that the point can be improved, I will be happy to do that.<br />
<br />
Ciao,<br />
<br />
[[User:Wilcomir|Wilcomir]] ([[User talk:Wilcomir|talk]]) 09:14, 3 January 2021 (UTC)<br />
<br />
:Well, the existing section about a Windows problem is actually solved by configuring the Linux host. I think anything involving configuration or installation of programs in Windows is not appropriate for long troubleshooting sections. At most, they could be mentioned in a short reference to other sites which describe the problem in detail. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:34, 3 January 2021 (UTC)<br />
<br />
== <s>XDG configuration for Vim</s> ==<br />
<br />
Hi Lahwaacz,<br />
<br />
You have reverted the updated Notes for Vim on [[XDG Base Directory]], because "copy-pasted from a blog post".<br />
<br />
The problem is, not only is the configuration presented currently also copied from a blog post too, but is already 10 years old.<br />
<br />
Would it be OK, if we bring back the more up to date version? Or at least remove the obsolete one and leave link to newer?<br><br />
(Although I think a copy on wiki would be beneficial in case my blog ceases to exist)<br />
<br />
[[User:Jorengarenar|Jorengarenar]] ([[User talk:Jorengarenar|talk]]) 02:05, 12 January 2021 (UTC)<br />
<br />
:OK let's close this. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:49, 29 August 2021 (UTC)<br />
<br />
== Root on ZFS draft ==<br />
<br />
Hi, I submitted [https://github.com/openzfs/openzfs-docs/pull/104 a Root on ZFS draft] to official doc repo.<br />
<br />
In the draft, the following directories are separated from root filesystem:<br />
home,root,srv,usr/local,var/log,var/spool,var/tmp<br />
<br />
Is this appropriate for Arch Linux? Or do you have any suggestion on the draft?<br />
Any comment is appreciated.<br />
[[User:M0p|M0p]] ([[User talk:M0p|talk]]) 01:28, 23 January 2021 (UTC)<br />
<br />
== Re: undo GRUB - Common installation errors ==<br />
<br />
Concerning your undo of [https://wiki.archlinux.org/index.php?title=GRUB&diff=next&oldid=649799 Add the error message `Could not prepare Boot variable: No space left on device`)]<br />
Is there a better place to for this Information? One can find the solution in various forums, but I thought it could be helpful to have it in this wiki somewhere. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 12:51, 25 January 2021 (UTC)<br />
<br />
:The error message is not specific to the {{ic|/sys/fs/pstore/}} filesystem (which does not even seem to be used by default on Arch...) Where did you find that? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:16, 25 January 2021 (UTC)<br />
<br />
::I did not find anything Arch specific, but this post about Debian helped: [https://donjajo.com/fix-grub-efibootmgr-not-set-variable-no-space-left-device/ Post]. I also found something about [https://askubuntu.com/questions/1072618/could-not-prepare-boot-variable-no-space-left-on-device-grub-install-error-ef /sys/fs/efi/efivars/dump-*] The problem is that the actual efi-partition does not seam to be the problem, there is more than 70% space left. If there is better information to guide the user in the right direction that wuld be more helpful. This is what I found worked, but I admit that I don't know much about how grub operates. [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 16:20, 25 January 2021 (UTC)<br />
<br />
:::This wiki ''is'' Arch specific so old posts about Debian or Ubuntu do not apply. Even if they did, this is hardly a ''common'' installation problem. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:29, 26 January 2021 (UTC)<br />
<br />
::::I know that, and would not have put it there if it didn't occur on my Arch Linux installation. If this is something that should not be documented in this wiki, I understand that. Is there any other place you would recommend? An issue for grub-install maybe? [[User:ModProg|ModProg]] ([[User talk:ModProg|talk]]) 22:24, 26 January 2021 (UTC)<br />
<br />
== Kernel Compilation time ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Kernel&diff=next&oldid=650896 link]<br />
<br />
I don't think we should judge information by what is obvious to experts.<br />
People might have experience with compilation of other programs, which mostly is fast, and then there is the kernel which takes forever to compile.<br />
I think it does not hurt anyone to make people aware of it.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:03, 6 February 2021 (UTC)<br />
<br />
:It is an unnecessary information without a definite answer which can even be [https://html.duckduckgo.com/html?q=how%20long%20does%20it%20take%20to%20compile%20Linux%20kernel searched elsewhere]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:23, 6 February 2021 (UTC)<br />
<br />
:: I disagree, with that argument nearly any tip and note is unnecessary. These things are intended to inform users about things that should be taken into consideration and that are different from the norm.<br />
:: Also do you search for the compilation time for every program you intend to compile? I don't.<br />
:: Furthermore this info is included, why not tell it to people directly on the start, so they don't read over it? <br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:36, 6 February 2021 (UTC)<br />
<br />
:::If someone wants to compile the Linux kernel, they should obviously expect that it will take ''some time''. Stating that it "can take up to several hours" does not make sense without referring to a specific hardware. Obviously, it will take much longer on a poor laptop than on a powerful workstation with a many-core processor, but people can assume that themselves. Without a reference to a specific hardware, the note is unnecessarily discouraging because the compilation can be as fast as some tens of minutes - it is by far not the most expensive package to compile...<br />
:::As you said, people can find better notes later along with advices to enable parallel build etc. which is all that's needed IMO.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:03, 6 February 2021 (UTC)<br />
<br />
== Wayland style ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Wayland&diff=prev&oldid=650979 link]<br />
<br />
I think in the old version it was much easier to read the "source code", so I don't see why there can't be spaces between it.<br />
Things shouldn't be complicated more than necessary.<br />
<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 14:11, 6 February 2021 (UTC)<br />
<br />
:Most templates on the wiki are written without spaces around the |. When we [https://github.com/archlinux/archwiki/pull/32 switch the editor], there will even be syntax highlighting. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:25, 6 February 2021 (UTC)<br />
<br />
== Bluetooth keyboard ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php/Bluetooth_keyboard link]<br />
<br />
On your last change you said "not specific to keyboards, all of this is already mentioned on the Bluetooth page", the point is that this is extremely relevant for bluetooth keyboard since it is required to perform the login! If this little piece cannot be duplicated I would suggest at least to leave a link saying "If you want to autoconnect at boot please refer to...". I'm new here and I would not touch it further, but please evaluate the suggestion (this is because after reading bluetooth keyboard page and not finding the solution I had to look for it on forums)<br />
<br />
{{unsigned|21:17, 20 February 2021|Stevexyz}}<br />
<br />
:Well, basically the whole page is flagged to be merged with the main [[Bluetooth]] page, so it's expected to be incomplete. Other tips may always be found on a more general page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:40, 21 February 2021 (UTC)<br />
<br />
== Re: Steam Needs to be online error ==<br />
<br />
Reference: [https://wiki.archlinux.org/index.php?title=Steam/Troubleshooting&diff=next&oldid=653073 link]<br />
<br />
The problem here is that DNS resolution in general works already (yes even outside browsers), i.e. <br />
<br />
dig media.steampowered.com<br />
<br />
would run successfully, but the Steam client couldn’t resolve it. The DNS request from 'dig' shows up in my nameserver’s log, the one Steam should send doesn’t. This indicates it might indeed a problem specific to Steam, and it’s not as easy as just say "go fix your DNS resolution", as it already may work correctly for everything but Steam.<br />
<br />
Additionally, at no point does [[Domain name resolution]] even mention nscd, so you effectively removed a fix/workaround for the problem from the Wiki. So I was definitely not "duplicating an article" here. [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 08:12, 22 February 2021 (UTC)<br />
<br />
:Could I please hear your opinion on this? I’d be happy to just add something along the lines of "if you made sure DNS resolution works but Steam still can’t resolve it, try additionally enabling the nscd service" to the Steam troubleshooting page. Unfortounately I don’t know why running the service helps, but I’d still like to give others an easier time finding this solution than I had myself. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 09:15, 28 February 2021 (UTC)<br />
<br />
::Hi, I'm sorry for the delay. Could you test if using a different program for DNS caching (e.g. [[systemd-resolved]]) instead of {{ic|nscd.service}} fixes the problem? If not, then it's probably not due to DNS - {{man|8|nscd}} actually caches more than just DNS. Also if you have a reference to some website where you found about nscd, it would be nice to add it. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:22, 28 February 2021 (UTC)<br />
<br />
:::No worries. Using [[systemd-resolved]] for DNS resolution (and caching I guess, I wasn’t aware it does that, too) was a thing I did try, but that didn’t fix it for me. The place I found out about nscd fixing it was actually the [https://bbs.archlinux.org/viewtopic.php?id=263356 Arch forums]. When I search the web for Steam in combination with nscd, all I can seem to find are more forum entries of people that don’t know why that fixes it either. I can try a bit to find out what nscd does to make it work, but I’m not too confident I will be successful. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 14:51, 28 February 2021 (UTC)<br />
<br />
::::Okay, so {{ic|nscd}} allows to [https://man7.org/linux/man-pages/man5/nscd.conf.5.html dis-/enable caching per service], and it’s indeed enabling it for {{ic|hosts}} that makes it work. That’s weird though, since [[systemd-resolved]] has caching enabled by default, and using it for resolution didn’t make {{ic|steam}} work for me. Leads me to think that I didn’t set it up correctly, although resolving via {{ic|dig}} *did* work. Since [[steam]] depends on [[Name Service Switch]], I tried resolving using {{ic|getent}} manually with nscd disabled, but that worked while steam did not. I’m not really sure what to make of this, since I have no idea how this low level networking/resolving stuff works really. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 15:39, 28 February 2021 (UTC)<br />
<br />
:::::Hmm, I don't know the details either. Steam needs the multilib packages so maybe that's part of the problem. Could you add your findings to the section and use [[Template:Expansion]] for the missing details? Maybe someone can figure it out. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 17:44, 28 February 2021 (UTC)<br />
<br />
::::::Sure, I can do that. I’ll probably need a minute to figure out how to use the template though, but I should have the time later today. Thanks for your input on this. -- [[User:Irimi1|Irimi1]] ([[User talk:Irimi1|talk]]) 17:56, 28 February 2021 (UTC)<br />
<br />
== Removal of website link ==<br />
<br />
Refers to this: https://wiki.archlinux.org/index.php?title=PipeWire&diff=next&oldid=653701<br />
<br />
I don't understand why that has to be removed. The official website should be always worth a mention, even if it is somehow mentioned in the text already.<br />
[[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:02, 28 February 2021 (UTC)<br />
<br />
:The "See also" section is for additional links, it is not intended as a collection of all links used on a page. Adding links which are clearly mentioned in the appropriate place only clutters the list. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:24, 28 February 2021 (UTC)<br />
<br />
:: There are just three links and only one of them is really useful, the others could maybe even be removed as they link to old blog posts.<br />
:: I can only repeat myself, that things don't always have to be made more complicated than necessary.<br />
:: The official website is a central point which links to many more useful ressources, so it's one link for much information.<br />
:: [[User:G3ro|G3ro]] ([[User talk:G3ro|talk]]) 20:34, 28 February 2021 (UTC)<br />
<br />
== Removal of bootia32.efi generation procedure from X205TA install page. ==<br />
<br />
Those [https://wiki.archlinux.org/index.php?title=ASUS_x205ta&diff=596239&oldid=562734 instructions] were really straightforward and useful, imho in comparison present ones require too much material to be confident with. I think it's (paradoxically) way easier to generate the file than to configure a `grub.cfg` from zero to boot a live cd. Can we undo the edit? Otherwise we could put them in a new page or section in the GRUB page and link to them maybe. [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 05:07, 4 March 2021 (UTC)<br />
<br />
:If there is something wrong with the information on the [https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Booting_64-bit_kernel_on_32-bit_UEFI general page], it should be improved instead of describing the same procedure in a different way on a completely unrelated page. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:16, 6 March 2021 (UTC)<br />
<br />
:: I didn't know we had that info in the UEFI article. I think it could be appropriate to insert the [https://en.wikipedia.org/wiki/Template:See_also#Examples See also] archwiki equivalent (which I couldn't find) for UEFI page on top of the aforementioned section, what do you think? [[User:Tallero|Tallero]] ([[User talk:Tallero|talk]]) 13:28, 7 March 2021 (UTC)<br />
<br />
:::Well, the removed section was previously flagged with "Duplicates [[Unified Extensible Firmware Interface#Booting 64-bit kernel on 32-bit UEFI]]"...<br />
:::Also the laptops pages are usually related to most of the general pages on this wiki, adding all of them would be pretty useless. Users should not expect to find everything on a single laptop page, they should always check if there is a general page for their topic with more details.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:58, 7 March 2021 (UTC)<br />
<br />
== Re: Show how to use systemd/Timers with wg-quick@.service ==<br />
<br />
I don't think using service is the appropriate when you want to start Wireguard at boot. For most people connecting to a VPN is not exactly part system startup.<br />
A timer should more appropriate.<br />
[[User:ENV25|ENV25]] ([[User talk:ENV25|talk]]) 10:03, 11 April 2021 (UTC)<br />
<br />
:I don't see how OnBootSec=1min is more appropriate than an automatically starting service. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:19, 11 April 2021 (UTC)<br />
<br />
== USB flash installation medium (BIOS bootable) ==<br />
<br />
Hi, about your [https://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=next&oldid=673926 revert]: "making the partition bootable is discussed below"<br />
Do you mean installing syslinux and `dd` the [gpt]mbr with "discussed below"? This was not enought for my setup (Sandisk Ultra 64GB, Dell XPS 9370) to make the partition BIOS bootable. It did work right after I checked "Legacy BIOS Bootable" checkbox using gnome-disks.<br />
<br />
{{Unsigned|13:42, 30 May 2021 (UTC)|Auipga}}<br />
<br />
:Yes, that's what I meant. If it does not work, it should be fixed rather than providing a duplicate instruction without a reason. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:16, 30 May 2021 (UTC)<br />
<br />
== Systemd-networkd systemd-networkd-wait-online.service discussion modifications ==<br />
<br />
I'm not sure why you're reverting my edits.<br />
<br />
You said: "''empty ExecStart is explained in Systemd#Examples''"<br />
<br />
Exactly: Systemd#Examples clearly states "''As another example, in order to replace the ExecStart directive for a unit that is '''not of type oneshot'''''"<br />
<br />
'''systemd-networkd-wait-online''' is a oneshot service. By having the superfluous empty ExecStart you're just confusing people.<br />
<br />
Regarding the file naming, yes the name is irrelevant, but it's generally helpful to non-expert users to stick to canonical naming conventions.<br />
<br />
Please make sure you're on solid ground before reverting edits; you're just discouraging people from engaging with the Wiki. Thanks. [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 16:51, 9 June 2021 (UTC)<br />
<br />
:{{man|5|systemd.service}} says: "Unless Type= is oneshot, exactly one command must be given. When Type=oneshot is used, zero or more commands may be specified."<br />
:So when a service is not oneshot, users ''must'' clear ExecStart before adding a modified command in the drop-in file. If a service is oneshot, they ''may or may not'' clear ExecStart, since the service may have multiple ExecStart commands.<br />
:In case of systemd-networkd-wait-online, I don't see why you would want to run multiple instances with different options: one to wait for ''all'' links (which is the default command) and another one to wait for ''any'' link (which is the command in the drop-in example). So clearing ExecStart really makes sense for systemd-networkd-wait-online.<br />
:— [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:44, 9 June 2021 (UTC)<br />
<br />
== Pacman: Install missing dependencies ==<br />
<br />
Hi. [https://wiki.archlinux.org/index.php?title=Pacman&type=revision&diff=690774&oldid=690762 "Pacman" Revision as of 21:50, 4 August 2021 (undo)] - maybe at least put that into [[System_maintenance#Avoid_certain_pacman_commands]]?<br />
<br />
[[User:Galeksandrp|Galeksandrp]] ([[User talk:Galeksandrp|talk]])<br />
<br />
:[[System_maintenance#Avoid_certain_pacman_commands]] already mentions {{ic|-Rdd}}. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:12, 14 August 2021 (UTC)<br />
<br />
== DPMS: "\033[9;0]" ==<br />
<br />
Hi. It seems that you removed {{ic|echo -ne "\033[9;0]"}} from [[Display Power Management Signaling|DPMS]]<br />
<br />
https://wiki.archlinux.org/index.php?title=Display_Power_Management_Signaling&diff=629705&oldid=625073<br />
<br />
[https://www.denx.de/wiki/view/DULG/SwitchOffScreenSaverAndBlinkingCursor A DULG page] and [https://unix.stackexchange.com/a/23636 a U&L post] brought me here.<br />
<br />
May I ask (1) if this method is still working; and (2) where is this escape sequence documented? [not found in {{man|4|console_codes}}]<br />
<br />
Thanks.<br />
<br />
{{Unsigned|05:23, 15 August 2021 (UTC)|PXf}}<br />
<br />
:[[Display Power Management Signaling#DPMS interaction in a Linux console with setterm]] says that setterm works by writing escape codes to the terminal device. The first subsection shows how to reverse-engineer the escape codes. Note that the escape codes are an implementation detail that users should not be concerned with, their documentation is certainly not our job. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:40, 15 August 2021 (UTC)<br />
<br />
== Linux console/Keyboard configuration ==<br />
<br />
Hi, you recently reverted my edit https://wiki.archlinux.org/index.php?title=Linux_console/Keyboard_configuration&oldid=693887. The reason I made that edit, was that I used to put my custom keymap in {{ic|/usr/local/share/kbd/keymaps/personal}} per the previous version of the wiki page. But this doesn't work with ''sd-vconsole'', as it's include files don't get loaded. Your suggested workaround by adding all required files using [[mkinitcpio#BINARIES and FILES|mkinitcpio BINARIES and FILES]] is rather tedious, as all the include files need to be in there, added by hand. This is done automatically by ''sd-vconsole'' if the file was put in {{ic|/usr/share/kbd/keymaps/}}. The reason I made this edit is due to https://bugs.archlinux.org/task/71788. See Giancarlo Razzolini's comment. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:43, 2 September 2021 (UTC)<br />
<br />
:It's just one custom file under {{ic|/usr/local}} and one entry in {{ic|FILES}}. What is so tedious about it? — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 10:37, 2 September 2021 (UTC)<br />
<br />
:: It's not just one file. All the dependencies need to be included too under {{ic|/usr/share/kbd/keymaps/}}. There are quite a few in my case, when I just include ''us.map'' to modify it slightly. See the ''sd-vconsole'' hook script. That script has a part where it finds all the dependencies of a keymap.<br />
<br />
:: * ''/usr/share/kbd/keymaps/i386/include/compose.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/euro1.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-keys-bare.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/linux-with-alt-and-altgr.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/include/qwerty-layout.inc''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/personal.map''<br />
:: * ''/usr/share/kbd/keymaps/i386/qwerty/us.map''<br />
:: * ''/usr/share/kbd/keymaps/include/compose.latin1''<br />
<br />
:: [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 12:01, 2 September 2021 (UTC)<br />
<br />
::: I moved this to the talk page so I remember it and others can discuss too. [[User:Simonzack|Simonzack]] ([[User talk:Simonzack|talk]]) 09:18, 4 September 2021 (UTC)<br />
<br />
::: Oh, I see. In that case I suggest we add a tip like this:<br />
::: {{Tip|If you use the {{ic|sd-vconsole}} [[mkinitcpio#Common hooks|mkinitcpio hook]] instead of {{ic|keymap}}, keymaps located under {{ic|/usr/local}} as well as their dependencies from {{ic|/usr/share/kbd/keymaps}} need to be manually specified in the {{ic|FILES}} array in {{ic|mkinitcpio.conf}}. On the other hand, custom files located in {{ic|/usr/share/kbd/keymaps}} will be added automatically when configured in {{ic|/etc/vconsole.conf}}.}}<br />
::: Because this is relevant only for people using the {{ic|sd-vconsole}} hook and otherwise it does not make sense to pollute {{ic|/usr/share/kbd/keymaps}} with custom files.<br />
::: — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:55, 5 September 2021 (UTC)<br />
<br />
== cow_* ==<br />
<br />
Hi Lahwaacz. About the [https://wiki.archlinux.org/index.php?title=Archiso&diff=next&oldid=692981 how/why issue] (there will be no more &lt;!-- --&gt;). What if, for once, that I want to install some large packages after booting archiso, and would not bother modifying packages.x86_64 and building again? [https://www.memesmonkey.com/topic/works+on+my+machine <s>''on my machine''</s>] Darren "Un1Gfn" "[[User:PXf|PXf]]" Ng ([[User talk:PXf|talk]]) 08:18, 12 October 2021 (UTC)<br />
<br />
:It is a subsection of "Tips and tricks", not "Troubleshooting", so it should start with a clear motivation saying ''why'' the tip is useful, rather than an error message that the user has no idea if they will face or not. If you have such description, feel free to rewrite the section. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 05:42, 13 October 2021 (UTC)<br />
<br />
::What about making it a subsection of "[[Archiso#Troubleshooting|Troubleshooting]]" and renaming it to {{ic|partition / too full}}? [[User:PXf|PXf]] ([[User talk:PXf|talk]]) 06:45, 13 October 2021 (UTC)<br />
<br />
:::It's better to motivate it as a tip/trick rather than solve the problem after it happens. — [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:48, 13 October 2021 (UTC)<br />
<br />
== Install Arch Linux via Docker ==<br />
<br />
(Undo revision 699881 by Oliver (talk) - installing arch-install-scripts does not get the image to "the same footing" as the archiso, even installing something for the first time is not an excuse to violate Help:Style#Package management instructions)<br />
<br />
'the same footing' may be poor choice of wording maybe, but 'installing something for the first time' is NOT what is going on here really. If we quote the style guide:<br />
<br />
''every Arch user should know pacman's article by memory''<br />
<br />
<br />
The thing is, this is NOT an Arch user yet. They have no idea what's going on, how to do stuff and just want to get started and installed. You can't expect _new_ not-yet-a user, to figure out everything in a daunting installation; by being a smart-bum about it. Yes, the style guide is completely correct on all other points. But I would think that this is the exception, rather then the rule. Help your new users a little. Introduce them gentle with open arms. From a 'first UX kind of way, this is horrible to treat your potentially new users.<br />
<br />
[[User:Oliver|Oliver]] ([[User talk:Oliver|talk]]) 17:40, 26 October 2021 (UTC)</div>Oliverhttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_via_Docker&diff=699881Install Arch Linux via Docker2021-10-24T15:52:41Z<p>Oliver: Add a little bit of explanation what is going why the arch-install-scripts are needed, and again, make it copy-pasteable</p>
<hr />
<div>[[Category:Installation process]]<br />
{{Style|Formatting does not comply to the guidelines, see [[Help:Style]].}}<br />
<br />
This document is a guide for installing [[Arch Linux]] using the official [Arch Linux docker](https://hub.docker.com/_/archlinux). For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation [https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html]. A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available. Furthermore a working [[Docker]] setup on the host is required. While technically it is certainly possible to use any qemu supported host to install Arch with, this guide will not cover this however.<br />
<br />
== Pre-installation ==<br />
<br />
This guide assumes that the host system is already pre-configured with regards to normally expected things. E.g. the time is setup correctly, internet connection is working normally, EFI mode if required is setup correctly etc.<br />
<br />
=== Prepare an installation medium ===<br />
<br />
The installation requires a target directory to which Arch Linux will be installed. Any writable directory can be used, but it is quite likely that the target directory has a partition or volume mounted that will server as the root disk.<br />
<br />
==== Full disk partitions ====<br />
<br />
If a full disk is being used as a target, it may need to be formatted. For details see [[Installation guide#Partition the disks]] as the same partitioning instructions and order can be followed from there. All the same restrictions and requirements as from there apply as well.<br />
<br />
Likewise, the new disk will also needed to be formatted. The instructions from [[Installation guide#Format the partitions]] can be used for this as well.<br />
<br />
==== Volumes ====<br />
<br />
When using filesystems such as [[btrfs]] or zfs, filesystem volumes are an option to use. Depending on what filesystem is used, creating them uses their own list of commands. In this guide, btrfs will be used as an example.<br />
<br />
First, a root volume for Arch Linux is created. This command assumes the current working directory is the btrfs root volume (subvolid=5), but anywhere could be used. If a different location is used, within an existing hierarchy, keep this in mind when later defining fstab and similar. Also note, that as the Arch Linux specific volume is created on a mounted (root) volume, it could be the case that the underlying stack is using (full)disk encryption.<br />
<br />
# btrfs subvolume create "arch_root"<br />
<br />
{{Note|To get the root volume, mount the btrfs with the {{ic|1=subvolid=5}} option.}}<br />
<br />
=== Mount the file systems ===<br />
<br />
The following section assumes the location Arch Linux will be installed into ''/tmp/target''. It is thus required that the partition is thus mounted there. Using a btrfs subvolume called '''arch_root''', with ''autodefrag'' and ''LZO compression'' enabled would look as:<br />
<br />
# mkdir -p /tmp/target<br />
# mount /dev/disk /tmp/target -o subvol=arch_root,compress=lzo,autodefrag<br />
<br />
The instructions from [[Installation guide#Mount the file systems]] can be used for this as well.<br />
<br />
== Installation ==<br />
<br />
=== Launching the container ===<br />
<br />
The remainder of the installation will be done inside a docker container, abbreviated with ADC, Arch Docker Container.<br />
<br />
# docker run \<br />
--env PS1="ADC(\#)[\d \T:\w]\\$ " \<br />
--interactive \<br />
--privileged \<br />
--rm \<br />
--tty \<br />
--volume "/tmp/target:/target" \<br />
"index.docker.io/library/archlinux:latest" /bin/sh<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. In the docker container we first install [[reflector]], which updates the mirror list by choosing 70 most recently synchronized HTTPS mirrors and sorting them by download rate. [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/system/reflector.service]<br />
First we have to [[install]] [[reflector]] (and its dependency [[rsync]]) in the docker container to be able to use it.<br />
<br />
# pacman --sync --refresh reflector rsync<br />
# reflector [--country <country>] \<br />
--latest 5 \<br />
--save "/etc/pacman.d/mirrorlist" \<br />
--sort rate<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. Ensure to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
'''Note:''' The [[reflector]] package and its dependencies are only installed/needed in the docker container to populate the mirrorlist file. These packages (and others from this guide) won't be available in the final installation.<br />
<br />
=== Install essential packages ===<br />
<br />
Make sure that {{Pkg|arch-install-scripts}} is installed in the Docker container. This package contains the core scripts required to run an Arch Linux installation, and installing these puts the container in the same footing as the installation medium.<br />
<br />
# pacman --sync --refresh arch-install-scripts<br />
<br />
From here on the default installation can be followed, starting at chapter [[Installation guide#Install essential packages]].<br />
<br />
== Configure the system ==<br />
<br />
Follow the instructions in [[Installation guide#Configure the system]]. Replace {{ic|/mnt}} with {{ic|/target}} as appropriate.<br />
<br />
== Reboot ==<br />
<br />
Exit the docker container by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R "/target"}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
With a correctly setup boot loader, a reboot should now be possible into the freshly installed Arch Linux.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_via_Docker&diff=699880Install Arch Linux via Docker2021-10-24T15:48:50Z<p>Oliver: Inform the user where these packages will be living</p>
<hr />
<div>[[Category:Installation process]]<br />
{{Style|Formatting does not comply to the guidelines, see [[Help:Style]].}}<br />
<br />
This document is a guide for installing [[Arch Linux]] using the official [Arch Linux docker](https://hub.docker.com/_/archlinux). For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation [https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html]. A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available. Furthermore a working [[Docker]] setup on the host is required. While technically it is certainly possible to use any qemu supported host to install Arch with, this guide will not cover this however.<br />
<br />
== Pre-installation ==<br />
<br />
This guide assumes that the host system is already pre-configured with regards to normally expected things. E.g. the time is setup correctly, internet connection is working normally, EFI mode if required is setup correctly etc.<br />
<br />
=== Prepare an installation medium ===<br />
<br />
The installation requires a target directory to which Arch Linux will be installed. Any writable directory can be used, but it is quite likely that the target directory has a partition or volume mounted that will server as the root disk.<br />
<br />
==== Full disk partitions ====<br />
<br />
If a full disk is being used as a target, it may need to be formatted. For details see [[Installation guide#Partition the disks]] as the same partitioning instructions and order can be followed from there. All the same restrictions and requirements as from there apply as well.<br />
<br />
Likewise, the new disk will also needed to be formatted. The instructions from [[Installation guide#Format the partitions]] can be used for this as well.<br />
<br />
==== Volumes ====<br />
<br />
When using filesystems such as [[btrfs]] or zfs, filesystem volumes are an option to use. Depending on what filesystem is used, creating them uses their own list of commands. In this guide, btrfs will be used as an example.<br />
<br />
First, a root volume for Arch Linux is created. This command assumes the current working directory is the btrfs root volume (subvolid=5), but anywhere could be used. If a different location is used, within an existing hierarchy, keep this in mind when later defining fstab and similar. Also note, that as the Arch Linux specific volume is created on a mounted (root) volume, it could be the case that the underlying stack is using (full)disk encryption.<br />
<br />
# btrfs subvolume create "arch_root"<br />
<br />
{{Note|To get the root volume, mount the btrfs with the {{ic|1=subvolid=5}} option.}}<br />
<br />
=== Mount the file systems ===<br />
<br />
The following section assumes the location Arch Linux will be installed into ''/tmp/target''. It is thus required that the partition is thus mounted there. Using a btrfs subvolume called '''arch_root''', with ''autodefrag'' and ''LZO compression'' enabled would look as:<br />
<br />
# mkdir -p /tmp/target<br />
# mount /dev/disk /tmp/target -o subvol=arch_root,compress=lzo,autodefrag<br />
<br />
The instructions from [[Installation guide#Mount the file systems]] can be used for this as well.<br />
<br />
== Installation ==<br />
<br />
=== Launching the container ===<br />
<br />
The remainder of the installation will be done inside a docker container, abbreviated with ADC, Arch Docker Container.<br />
<br />
# docker run \<br />
--env PS1="ADC(\#)[\d \T:\w]\\$ " \<br />
--interactive \<br />
--privileged \<br />
--rm \<br />
--tty \<br />
--volume "/tmp/target:/target" \<br />
"index.docker.io/library/archlinux:latest" /bin/sh<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. In the docker container we first install [[reflector]], which updates the mirror list by choosing 70 most recently synchronized HTTPS mirrors and sorting them by download rate. [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/system/reflector.service]<br />
First we have to [[install]] [[reflector]] (and its dependency [[rsync]]) in the docker container to be able to use it.<br />
<br />
# pacman --sync --refresh reflector rsync<br />
# reflector [--country <country>] \<br />
--latest 5 \<br />
--save "/etc/pacman.d/mirrorlist" \<br />
--sort rate<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. Ensure to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
'''Note:''' The [[reflector]] package and its dependencies are only installed/needed in the docker container to populate the mirrorlist file. These packages (and others from this guide) won't be available in the final installation.<br />
<br />
=== Install essential packages ===<br />
<br />
Make sure that {{Pkg|arch-install-scripts}} is installed in the Docker container. Then follow [[Installation guide#Install essential packages]] to install packages into {{ic|/target}} using the {{man|8|pacstrap}} script.<br />
<br />
== Configure the system ==<br />
<br />
Follow the instructions in [[Installation guide#Configure the system]]. Replace {{ic|/mnt}} with {{ic|/target}} as appropriate.<br />
<br />
== Reboot ==<br />
<br />
Exit the docker container by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R "/target"}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
With a correctly setup boot loader, a reboot should now be possible into the freshly installed Arch Linux.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_via_Docker&diff=699878Install Arch Linux via Docker2021-10-24T15:46:29Z<p>Oliver: Add missing rsync dependency (bug?) WARNING: failed to rate rsync download (rsync://mirror.erickochen.nl/archlinux/community/os/x86_64/community.db): [Errno 2] No such file or directory: 'rsync'</p>
<hr />
<div>[[Category:Installation process]]<br />
{{Style|Formatting does not comply to the guidelines, see [[Help:Style]].}}<br />
<br />
This document is a guide for installing [[Arch Linux]] using the official [Arch Linux docker](https://hub.docker.com/_/archlinux). For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation [https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html]. A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available. Furthermore a working [[Docker]] setup on the host is required. While technically it is certainly possible to use any qemu supported host to install Arch with, this guide will not cover this however.<br />
<br />
== Pre-installation ==<br />
<br />
This guide assumes that the host system is already pre-configured with regards to normally expected things. E.g. the time is setup correctly, internet connection is working normally, EFI mode if required is setup correctly etc.<br />
<br />
=== Prepare an installation medium ===<br />
<br />
The installation requires a target directory to which Arch Linux will be installed. Any writable directory can be used, but it is quite likely that the target directory has a partition or volume mounted that will server as the root disk.<br />
<br />
==== Full disk partitions ====<br />
<br />
If a full disk is being used as a target, it may need to be formatted. For details see [[Installation guide#Partition the disks]] as the same partitioning instructions and order can be followed from there. All the same restrictions and requirements as from there apply as well.<br />
<br />
Likewise, the new disk will also needed to be formatted. The instructions from [[Installation guide#Format the partitions]] can be used for this as well.<br />
<br />
==== Volumes ====<br />
<br />
When using filesystems such as [[btrfs]] or zfs, filesystem volumes are an option to use. Depending on what filesystem is used, creating them uses their own list of commands. In this guide, btrfs will be used as an example.<br />
<br />
First, a root volume for Arch Linux is created. This command assumes the current working directory is the btrfs root volume (subvolid=5), but anywhere could be used. If a different location is used, within an existing hierarchy, keep this in mind when later defining fstab and similar. Also note, that as the Arch Linux specific volume is created on a mounted (root) volume, it could be the case that the underlying stack is using (full)disk encryption.<br />
<br />
# btrfs subvolume create "arch_root"<br />
<br />
{{Note|To get the root volume, mount the btrfs with the {{ic|1=subvolid=5}} option.}}<br />
<br />
=== Mount the file systems ===<br />
<br />
The following section assumes the location Arch Linux will be installed into ''/tmp/target''. It is thus required that the partition is thus mounted there. Using a btrfs subvolume called '''arch_root''', with ''autodefrag'' and ''LZO compression'' enabled would look as:<br />
<br />
# mkdir -p /tmp/target<br />
# mount /dev/disk /tmp/target -o subvol=arch_root,compress=lzo,autodefrag<br />
<br />
The instructions from [[Installation guide#Mount the file systems]] can be used for this as well.<br />
<br />
== Installation ==<br />
<br />
=== Launching the container ===<br />
<br />
The remainder of the installation will be done inside a docker container, abbreviated with ADC, Arch Docker Container.<br />
<br />
# docker run \<br />
--env PS1="ADC(\#)[\d \T:\w]\\$ " \<br />
--interactive \<br />
--privileged \<br />
--rm \<br />
--tty \<br />
--volume "/tmp/target:/target" \<br />
"index.docker.io/library/archlinux:latest" /bin/sh<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. In the docker container we first install [[reflector]], which updates the mirror list by choosing 70 most recently synchronized HTTPS mirrors and sorting them by download rate. [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/system/reflector.service]<br />
First we have to [[install]] [[reflector]] (and its dependency [[rsync]]) in the docker container to be able to use it.<br />
<br />
# pacman --sync --refresh reflector rsync<br />
# reflector [--country <country>] \<br />
--latest 5 \<br />
--save "/etc/pacman.d/mirrorlist" \<br />
--sort rate<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. Ensure to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
Make sure that {{Pkg|arch-install-scripts}} is installed in the Docker container. Then follow [[Installation guide#Install essential packages]] to install packages into {{ic|/target}} using the {{man|8|pacstrap}} script.<br />
<br />
== Configure the system ==<br />
<br />
Follow the instructions in [[Installation guide#Configure the system]]. Replace {{ic|/mnt}} with {{ic|/target}} as appropriate.<br />
<br />
== Reboot ==<br />
<br />
Exit the docker container by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R "/target"}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
With a correctly setup boot loader, a reboot should now be possible into the freshly installed Arch Linux.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_via_Docker&diff=699877Install Arch Linux via Docker2021-10-24T15:43:34Z<p>Oliver: This is the very first time a new user may be installing something with arch. Make sure the instruction is copy/pasteable instead of being only external links and having the user figure it out.</p>
<hr />
<div>[[Category:Installation process]]<br />
{{Style|Formatting does not comply to the guidelines, see [[Help:Style]].}}<br />
<br />
This document is a guide for installing [[Arch Linux]] using the official [Arch Linux docker](https://hub.docker.com/_/archlinux). For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation [https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html]. A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available. Furthermore a working [[Docker]] setup on the host is required. While technically it is certainly possible to use any qemu supported host to install Arch with, this guide will not cover this however.<br />
<br />
== Pre-installation ==<br />
<br />
This guide assumes that the host system is already pre-configured with regards to normally expected things. E.g. the time is setup correctly, internet connection is working normally, EFI mode if required is setup correctly etc.<br />
<br />
=== Prepare an installation medium ===<br />
<br />
The installation requires a target directory to which Arch Linux will be installed. Any writable directory can be used, but it is quite likely that the target directory has a partition or volume mounted that will server as the root disk.<br />
<br />
==== Full disk partitions ====<br />
<br />
If a full disk is being used as a target, it may need to be formatted. For details see [[Installation guide#Partition the disks]] as the same partitioning instructions and order can be followed from there. All the same restrictions and requirements as from there apply as well.<br />
<br />
Likewise, the new disk will also needed to be formatted. The instructions from [[Installation guide#Format the partitions]] can be used for this as well.<br />
<br />
==== Volumes ====<br />
<br />
When using filesystems such as [[btrfs]] or zfs, filesystem volumes are an option to use. Depending on what filesystem is used, creating them uses their own list of commands. In this guide, btrfs will be used as an example.<br />
<br />
First, a root volume for Arch Linux is created. This command assumes the current working directory is the btrfs root volume (subvolid=5), but anywhere could be used. If a different location is used, within an existing hierarchy, keep this in mind when later defining fstab and similar. Also note, that as the Arch Linux specific volume is created on a mounted (root) volume, it could be the case that the underlying stack is using (full)disk encryption.<br />
<br />
# btrfs subvolume create "arch_root"<br />
<br />
{{Note|To get the root volume, mount the btrfs with the {{ic|1=subvolid=5}} option.}}<br />
<br />
=== Mount the file systems ===<br />
<br />
The following section assumes the location Arch Linux will be installed into ''/tmp/target''. It is thus required that the partition is thus mounted there. Using a btrfs subvolume called '''arch_root''', with ''autodefrag'' and ''LZO compression'' enabled would look as:<br />
<br />
# mkdir -p /tmp/target<br />
# mount /dev/disk /tmp/target -o subvol=arch_root,compress=lzo,autodefrag<br />
<br />
The instructions from [[Installation guide#Mount the file systems]] can be used for this as well.<br />
<br />
== Installation ==<br />
<br />
=== Launching the container ===<br />
<br />
The remainder of the installation will be done inside a docker container, abbreviated with ADC, Arch Docker Container.<br />
<br />
# docker run \<br />
--env PS1="ADC(\#)[\d \T:\w]\\$ " \<br />
--interactive \<br />
--privileged \<br />
--rm \<br />
--tty \<br />
--volume "/tmp/target:/target" \<br />
"index.docker.io/library/archlinux:latest" /bin/sh<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. In the docker container we first install [[reflector]], which updates the mirror list by choosing 70 most recently synchronized HTTPS mirrors and sorting them by download rate. [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/system/reflector.service]<br />
First we have to [[install]] [[reflector]] in the docker container to be able to use it.<br />
<br />
# pacman --sync --refresh reflector<br />
# reflector [--country <country>] \<br />
--latest 5 \<br />
--save "/etc/pacman.d/mirrorlist" \<br />
--sort rate<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. Ensure to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
Make sure that {{Pkg|arch-install-scripts}} is installed in the Docker container. Then follow [[Installation guide#Install essential packages]] to install packages into {{ic|/target}} using the {{man|8|pacstrap}} script.<br />
<br />
== Configure the system ==<br />
<br />
Follow the instructions in [[Installation guide#Configure the system]]. Replace {{ic|/mnt}} with {{ic|/target}} as appropriate.<br />
<br />
== Reboot ==<br />
<br />
Exit the docker container by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R "/target"}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
With a correctly setup boot loader, a reboot should now be possible into the freshly installed Arch Linux.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_via_Docker&diff=699876Install Arch Linux via Docker2021-10-24T15:39:15Z<p>Oliver: Move device mounting to pre-install step and link to the main installation guide to keep things in sync.</p>
<hr />
<div>[[Category:Installation process]]<br />
{{Style|Formatting does not comply to the guidelines, see [[Help:Style]].}}<br />
<br />
This document is a guide for installing [[Arch Linux]] using the official [Arch Linux docker](https://hub.docker.com/_/archlinux). For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation [https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html]. A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available. Furthermore a working [[Docker]] setup on the host is required. While technically it is certainly possible to use any qemu supported host to install Arch with, this guide will not cover this however.<br />
<br />
== Pre-installation ==<br />
<br />
This guide assumes that the host system is already pre-configured with regards to normally expected things. E.g. the time is setup correctly, internet connection is working normally, EFI mode if required is setup correctly etc.<br />
<br />
=== Prepare an installation medium ===<br />
<br />
The installation requires a target directory to which Arch Linux will be installed. Any writable directory can be used, but it is quite likely that the target directory has a partition or volume mounted that will server as the root disk.<br />
<br />
==== Full disk partitions ====<br />
<br />
If a full disk is being used as a target, it may need to be formatted. For details see [[Installation guide#Partition the disks]] as the same partitioning instructions and order can be followed from there. All the same restrictions and requirements as from there apply as well.<br />
<br />
Likewise, the new disk will also needed to be formatted. The instructions from [[Installation guide#Format the partitions]] can be used for this as well.<br />
<br />
==== Volumes ====<br />
<br />
When using filesystems such as [[btrfs]] or zfs, filesystem volumes are an option to use. Depending on what filesystem is used, creating them uses their own list of commands. In this guide, btrfs will be used as an example.<br />
<br />
First, a root volume for Arch Linux is created. This command assumes the current working directory is the btrfs root volume (subvolid=5), but anywhere could be used. If a different location is used, within an existing hierarchy, keep this in mind when later defining fstab and similar. Also note, that as the Arch Linux specific volume is created on a mounted (root) volume, it could be the case that the underlying stack is using (full)disk encryption.<br />
<br />
# btrfs subvolume create "arch_root"<br />
<br />
{{Note|To get the root volume, mount the btrfs with the {{ic|1=subvolid=5}} option.}}<br />
<br />
=== Mount the file systems ===<br />
<br />
The following section assumes the location Arch Linux will be installed into ''/tmp/target''. It is thus required that the partition is thus mounted there. Using a btrfs subvolume called '''arch_root''', with ''autodefrag'' and ''LZO compression'' enabled would look as:<br />
<br />
# mkdir -p /tmp/target<br />
# mount /dev/disk /tmp/target -o subvol=arch_root,compress=lzo,autodefrag<br />
<br />
The instructions from [[Installation guide#Mount the file systems]] can be used for this as well.<br />
<br />
== Installation ==<br />
<br />
=== Launching the container ===<br />
<br />
The remainder of the installation will be done inside a docker container, abbreviated with ADC, Arch Docker Container.<br />
<br />
# docker run \<br />
--env PS1="ADC(\#)[\d \T:\w]\\$ " \<br />
--interactive \<br />
--privileged \<br />
--rm \<br />
--tty \<br />
--volume "/tmp/target:/target" \<br />
"index.docker.io/library/archlinux:latest" /bin/sh<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. In the docker container we first install [[reflector]], which updates the mirror list by choosing 70 most recently synchronized HTTPS mirrors and sorting them by download rate. [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/system/reflector.service]<br />
First we have to [[install]] [[reflector]] in the docker container to be able to use it.<br />
<br />
# reflector [--country <country>] \<br />
--latest 5 \<br />
--save "/etc/pacman.d/mirrorlist" \<br />
--sort rate<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. Ensure to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
Make sure that {{Pkg|arch-install-scripts}} is installed in the Docker container. Then follow [[Installation guide#Install essential packages]] to install packages into {{ic|/target}} using the {{man|8|pacstrap}} script.<br />
<br />
== Configure the system ==<br />
<br />
Follow the instructions in [[Installation guide#Configure the system]]. Replace {{ic|/mnt}} with {{ic|/target}} as appropriate.<br />
<br />
== Reboot ==<br />
<br />
Exit the docker container by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R "/target"}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
With a correctly setup boot loader, a reboot should now be possible into the freshly installed Arch Linux.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_via_Docker&diff=699875Install Arch Linux via Docker2021-10-24T15:28:09Z<p>Oliver: Ensure a disk is mounted before starting docker. This to ensure a logical flow through the document.</p>
<hr />
<div>[[Category:Installation process]]<br />
{{Style|Formatting does not comply to the guidelines, see [[Help:Style]].}}<br />
<br />
This document is a guide for installing [[Arch Linux]] using the official [Arch Linux docker](https://hub.docker.com/_/archlinux). For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation [https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html]. A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available. Furthermore a working [[Docker]] setup on the host is required. While technically it is certainly possible to use any qemu supported host to install Arch with, this guide will not cover this however.<br />
<br />
== Pre-installation ==<br />
<br />
This guide assumes that the host system is already pre-configured with regards to normally expected things. E.g. the time is setup correctly, internet connection is working normally, EFI mode if required is setup correctly etc.<br />
<br />
=== Prepare an installation medium ===<br />
<br />
The installation requires a target directory to which Arch Linux will be installed. Any writable directory can be used, but it is quite likely that the target directory has a partition or volume mounted that will server as the root disk.<br />
<br />
==== Full disk partitions ====<br />
<br />
If a full disk is being used as a target, it may need to be formatted. For details see [[Installation guide#Partition the disks]] as the same partitioning instructions and order can be followed from there. All the same restrictions and requirements as from there apply as well.<br />
<br />
Likewise, the new disk will also needed to be formatted. The instructions from [[Installation guide#Format the partitions]] can be used for this as well.<br />
<br />
==== Volumes ====<br />
<br />
When using filesystems such as [[btrfs]] or zfs, filesystem volumes are an option to use. Depending on what filesystem is used, creating them uses their own list of commands. In this guide, btrfs will be used as an example.<br />
<br />
First, a root volume for Arch Linux is created. This command assumes the current working directory is the btrfs root volume (subvolid=5), but anywhere could be used. If a different location is used, within an existing hierarchy, keep this in mind when later defining fstab and similar. Also note, that as the Arch Linux specific volume is created on a mounted (root) volume, it could be the case that the underlying stack is using (full)disk encryption.<br />
<br />
# btrfs subvolume create "arch_root"<br />
<br />
{{Note|To get the root volume, mount the btrfs with the {{ic|1=subvolid=5}} option.}}<br />
<br />
== Installation ==<br />
<br />
=== Mounting the device ===<br />
<br />
The following section assumes the location Arch Linux will be installed into ''/tmp/target''. It is thus required that the partition is thus mounted there. Using a btrfs subvolume called '''arch_root''', with ''autodefrag'' and ''LZO compression'' enabled would look as:<br />
<br />
# mkdir -p /tmp/target<br />
# mount /dev/disk /tmp/target -o subvol=arch_root,compress=lzo,autodefrag<br />
<br />
=== Launching the container ===<br />
<br />
The remainder of the installation will be done inside a docker container, abbreviated with ADC, Arch Docker Container.<br />
<br />
# docker run \<br />
--env PS1="ADC(\#)[\d \T:\w]\\$ " \<br />
--interactive \<br />
--privileged \<br />
--rm \<br />
--tty \<br />
--volume "/tmp/target:/target" \<br />
"index.docker.io/library/archlinux:latest" /bin/sh<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. In the docker container we first install [[reflector]], which updates the mirror list by choosing 70 most recently synchronized HTTPS mirrors and sorting them by download rate. [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/system/reflector.service]<br />
First we have to [[install]] [[reflector]] in the docker container to be able to use it.<br />
<br />
# reflector [--country <country>] \<br />
--latest 5 \<br />
--save "/etc/pacman.d/mirrorlist" \<br />
--sort rate<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. Ensure to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
Make sure that {{Pkg|arch-install-scripts}} is installed in the Docker container. Then follow [[Installation guide#Install essential packages]] to install packages into {{ic|/target}} using the {{man|8|pacstrap}} script.<br />
<br />
== Configure the system ==<br />
<br />
Follow the instructions in [[Installation guide#Configure the system]]. Replace {{ic|/mnt}} with {{ic|/target}} as appropriate.<br />
<br />
== Reboot ==<br />
<br />
Exit the docker container by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R "/target"}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
With a correctly setup boot loader, a reboot should now be possible into the freshly installed Arch Linux.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_via_Docker&diff=699873Install Arch Linux via Docker2021-10-24T15:22:35Z<p>Oliver: Add a hint on hour to obtain the root volume instead of an obscure reference</p>
<hr />
<div>[[Category:Installation process]]<br />
{{Style|Formatting does not comply to the guidelines, see [[Help:Style]].}}<br />
<br />
This document is a guide for installing [[Arch Linux]] using the official [Arch Linux docker](https://hub.docker.com/_/archlinux). For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation [https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html]. A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available. Furthermore a working [[Docker]] setup on the host is required. While technically it is certainly possible to use any qemu supported host to install Arch with, this guide will not cover this however.<br />
<br />
== Pre-installation ==<br />
<br />
This guide assumes that the host system is already pre-configured with regards to normally expected things. E.g. the time is setup correctly, internet connection is working normally, EFI mode if required is setup correctly etc.<br />
<br />
=== Prepare an installation medium ===<br />
<br />
The installation requires a target directory to which Arch Linux will be installed. Any writable directory can be used, but it is quite likely that the target directory has a partition or volume mounted that will server as the root disk.<br />
<br />
==== Full disk partitions ====<br />
<br />
If a full disk is being used as a target, it may need to be formatted. For details see [[Installation guide#Partition the disks]] as the same partitioning instructions and order can be followed from there. All the same restrictions and requirements as from there apply as well.<br />
<br />
Likewise, the new disk will also needed to be formatted. The instructions from [[Installation guide#Format the partitions]] can be used for this as well.<br />
<br />
==== Volumes ====<br />
<br />
When using filesystems such as [[btrfs]] or zfs, filesystem volumes are an option to use. Depending on what filesystem is used, creating them uses their own list of commands. In this guide, btrfs will be used as an example.<br />
<br />
First, a root volume for Arch Linux is created. This command assumes the current working directory is the btrfs root volume (subvolid=5), but anywhere could be used. If a different location is used, within an existing hierarchy, keep this in mind when later defining fstab and similar. Also note, that as the Arch Linux specific volume is created on a mounted (root) volume, it could be the case that the underlying stack is using (full)disk encryption.<br />
<br />
# btrfs subvolume create "arch_root"<br />
<br />
'''Note:''' To get the root volume, mount the btrfs partition as follows:<br />
# mount /dev/disk /tmp/btrfs -o subvolid=5<br />
<br />
== Installation ==<br />
<br />
=== Launching the container ===<br />
<br />
The remainder of the installation will be done inside a docker container, abbreviated with ADC, Arch Docker Container.<br />
<br />
# docker run \<br />
--env PS1="ADC(\#)[\d \T:\w]\\$ " \<br />
--interactive \<br />
--privileged \<br />
--rm \<br />
--tty \<br />
--volume "/tmp/target:/target" \<br />
"index.docker.io/library/archlinux:latest" /bin/sh<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. In the docker container we first install [[reflector]], which updates the mirror list by choosing 70 most recently synchronized HTTPS mirrors and sorting them by download rate. [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/system/reflector.service]<br />
First we have to [[install]] [[reflector]] in the docker container to be able to use it.<br />
<br />
# reflector [--country <country>] \<br />
--latest 5 \<br />
--save "/etc/pacman.d/mirrorlist" \<br />
--sort rate<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. Ensure to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
Make sure that {{Pkg|arch-install-scripts}} is installed in the Docker container. Then follow [[Installation guide#Install essential packages]] to install packages into {{ic|/target}} using the {{man|8|pacstrap}} script.<br />
<br />
== Configure the system ==<br />
<br />
Follow the instructions in [[Installation guide#Configure the system]]. Replace {{ic|/mnt}} with {{ic|/target}} as appropriate.<br />
<br />
== Reboot ==<br />
<br />
Exit the docker container by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R "/target"}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
With a correctly setup boot loader, a reboot should now be possible into the freshly installed Arch Linux.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_via_Docker&diff=699872Install Arch Linux via Docker2021-10-24T15:18:09Z<p>Oliver: Match Arch Docker Container abbreviation with PS1</p>
<hr />
<div>[[Category:Installation process]]<br />
{{Style|Formatting does not comply to the guidelines, see [[Help:Style]].}}<br />
<br />
This document is a guide for installing [[Arch Linux]] using the official [Arch Linux docker](https://hub.docker.com/_/archlinux). For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation [https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html]. A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available. Furthermore a working [[Docker]] setup on the host is required. While technically it is certainly possible to use any qemu supported host to install Arch with, this guide will not cover this however.<br />
<br />
== Pre-installation ==<br />
<br />
This guide assumes that the host system is already pre-configured with regards to normally expected things. E.g. the time is setup correctly, internet connection is working normally, EFI mode if required is setup correctly etc.<br />
<br />
=== Prepare an installation medium ===<br />
<br />
The installation requires a target directory to which Arch Linux will be installed. Any writable directory can be used, but it is quite likely that the target directory has a partition or volume mounted that will server as the root disk.<br />
<br />
==== Full disk partitions ====<br />
<br />
If a full disk is being used as a target, it may need to be formatted. For details see [[Installation guide#Partition the disks]] as the same partitioning instructions and order can be followed from there. All the same restrictions and requirements as from there apply as well.<br />
<br />
Likewise, the new disk will also needed to be formatted. The instructions from [[Installation guide#Format the partitions]] can be used for this as well.<br />
<br />
==== Volumes ====<br />
<br />
When using filesystems such as [[btrfs]] or zfs, filesystem volumes are an option to use. Depending on what filesystem is used, creating them uses their own list of commands. In this guide, btrfs will be used as an example.<br />
<br />
First, a root volume for Arch Linux is created. This command assumes the current working directory is the btrfs root volume (subvolid=5), but anywhere could be used. If a different location is used, within an existing hierarchy, keep this in mind when later defining fstab and similar. Also note, that as the Arch Linux specific volume is created on a mounted (root) volume, it could be the case that the underlying stack is using (full)disk encryption.<br />
<br />
# btrfs subvolume create "arch_root"<br />
<br />
== Installation ==<br />
<br />
=== Launching the container ===<br />
<br />
The remainder of the installation will be done inside a docker container, abbreviated with ADC, Arch Docker Container.<br />
<br />
# docker run \<br />
--env PS1="ADC(\#)[\d \T:\w]\\$ " \<br />
--interactive \<br />
--privileged \<br />
--rm \<br />
--tty \<br />
--volume "/tmp/target:/target" \<br />
"index.docker.io/library/archlinux:latest" /bin/sh<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. In the docker container we first install [[reflector]], which updates the mirror list by choosing 70 most recently synchronized HTTPS mirrors and sorting them by download rate. [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/system/reflector.service]<br />
First we have to [[install]] [[reflector]] in the docker container to be able to use it.<br />
<br />
# reflector [--country <country>] \<br />
--latest 5 \<br />
--save "/etc/pacman.d/mirrorlist" \<br />
--sort rate<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. Ensure to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
Make sure that {{Pkg|arch-install-scripts}} is installed in the Docker container. Then follow [[Installation guide#Install essential packages]] to install packages into {{ic|/target}} using the {{man|8|pacstrap}} script.<br />
<br />
== Configure the system ==<br />
<br />
Follow the instructions in [[Installation guide#Configure the system]]. Replace {{ic|/mnt}} with {{ic|/target}} as appropriate.<br />
<br />
== Reboot ==<br />
<br />
Exit the docker container by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R "/target"}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
With a correctly setup boot loader, a reboot should now be possible into the freshly installed Arch Linux.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_via_Docker&diff=699871Install Arch Linux via Docker2021-10-24T15:17:34Z<p>Oliver: Typo</p>
<hr />
<div>[[Category:Installation process]]<br />
{{Style|Formatting does not comply to the guidelines, see [[Help:Style]].}}<br />
<br />
This document is a guide for installing [[Arch Linux]] using the official [Arch Linux docker](https://hub.docker.com/_/archlinux). For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation [https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html]. A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available. Furthermore a working [[Docker]] setup on the host is required. While technically it is certainly possible to use any qemu supported host to install Arch with, this guide will not cover this however.<br />
<br />
== Pre-installation ==<br />
<br />
This guide assumes that the host system is already pre-configured with regards to normally expected things. E.g. the time is setup correctly, internet connection is working normally, EFI mode if required is setup correctly etc.<br />
<br />
=== Prepare an installation medium ===<br />
<br />
The installation requires a target directory to which Arch Linux will be installed. Any writable directory can be used, but it is quite likely that the target directory has a partition or volume mounted that will server as the root disk.<br />
<br />
==== Full disk partitions ====<br />
<br />
If a full disk is being used as a target, it may need to be formatted. For details see [[Installation guide#Partition the disks]] as the same partitioning instructions and order can be followed from there. All the same restrictions and requirements as from there apply as well.<br />
<br />
Likewise, the new disk will also needed to be formatted. The instructions from [[Installation guide#Format the partitions]] can be used for this as well.<br />
<br />
==== Volumes ====<br />
<br />
When using filesystems such as [[btrfs]] or zfs, filesystem volumes are an option to use. Depending on what filesystem is used, creating them uses their own list of commands. In this guide, btrfs will be used as an example.<br />
<br />
First, a root volume for Arch Linux is created. This command assumes the current working directory is the btrfs root volume (subvolid=5), but anywhere could be used. If a different location is used, within an existing hierarchy, keep this in mind when later defining fstab and similar. Also note, that as the Arch Linux specific volume is created on a mounted (root) volume, it could be the case that the underlying stack is using (full)disk encryption.<br />
<br />
# btrfs subvolume create "arch_root"<br />
<br />
== Installation ==<br />
<br />
=== Launching the container ===<br />
<br />
The remainder of the installation will be done inside a docker container, abbreviated with ADC, Arch Docker Container.<br />
<br />
# docker run \<br />
--env PS1="DAC(\#)[\d \T:\w]\\$ " \<br />
--interactive \<br />
--privileged \<br />
--rm \<br />
--tty \<br />
--volume "/tmp/target:/target" \<br />
"index.docker.io/library/archlinux:latest" /bin/sh<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. In the docker container we first install [[reflector]], which updates the mirror list by choosing 70 most recently synchronized HTTPS mirrors and sorting them by download rate. [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/system/reflector.service]<br />
First we have to [[install]] [[reflector]] in the docker container to be able to use it.<br />
<br />
# reflector [--country <country>] \<br />
--latest 5 \<br />
--save "/etc/pacman.d/mirrorlist" \<br />
--sort rate<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. Ensure to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
Make sure that {{Pkg|arch-install-scripts}} is installed in the Docker container. Then follow [[Installation guide#Install essential packages]] to install packages into {{ic|/target}} using the {{man|8|pacstrap}} script.<br />
<br />
== Configure the system ==<br />
<br />
Follow the instructions in [[Installation guide#Configure the system]]. Replace {{ic|/mnt}} with {{ic|/target}} as appropriate.<br />
<br />
== Reboot ==<br />
<br />
Exit the docker container by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R "/target"}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
With a correctly setup boot loader, a reboot should now be possible into the freshly installed Arch Linux.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_via_Docker&diff=699870Install Arch Linux via Docker2021-10-24T15:16:33Z<p>Oliver: Update docker container URI to match preferred URI's</p>
<hr />
<div>[[Category:Installation process]]<br />
{{Style|Formatting does not comply to the guidelines, see [[Help:Style]].}}<br />
<br />
This document is a guide for installing [[Arch Linux]] using the official [Arch Linux docker](https://hub.docker.com/_/archlinux). For alternative means of installation, see [[:Category:Installation process]].<br />
<br />
Before installing, it would be advised to view the [[FAQ]]. For conventions used in this document, see [[Help:Reading]]. In particular, code examples may contain placeholders (formatted in {{ic|''italics''}}) that must be replaced manually.<br />
<br />
For more detailed instructions, see the respective [[ArchWiki]] articles or the various programs' [[man page]]s, both linked from this guide. For interactive help, the [[IRC channel]] and the [https://bbs.archlinux.org/ forums] are also available.<br />
<br />
Arch Linux should run on any [[Wikipedia:X86-64|x86_64]]-compatible machine with a minimum of 512 MiB RAM, though more memory is needed to boot the live system for installation [https://lists.archlinux.org/pipermail/arch-releng/2020-May/003957.html]. A basic installation should take less than 2 GiB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available. Furthermore a working [[Docker]] setup on the host is required. While technically it is certainly possible to use any qemu supported host to install Arch with, this guide will not cover this however.<br />
<br />
== Pre-installation ==<br />
<br />
This guide assumes that the host system is already pre-configured with regards to normally expected things. E.g. the time is setup correctly, internet connection is working normally, EFI mode if required is setup correctly etc.<br />
<br />
=== Prepare an installation medium ===<br />
<br />
The installation requires a target directory to which Arch Linux will be installed. Any writable directory can be used, but it is quite likely that the target directory has a partition or volume mounted that will server as the root disk.<br />
<br />
==== Full disk partitions ====<br />
<br />
If a full disk is being used as a target, it may need to be formatted. For details see [[Installation guide#Partition the disks]] as the same partitioning instructions and order can be followed from there. All the same restrictions and requirements as from there apply as well.<br />
<br />
Likewise, the new disk will also needed to be formatted. The instructions from [[Installation guide#Format the partitions]] can be used for this as well.<br />
<br />
==== Volumes ====<br />
<br />
When using filesystems such as [[btrfs]] or zfs, filesystem volumes are an option to use. Depending on what filesystem is used, creating them uses their own list of commands. In this guide, btrfs will be used as an example.<br />
<br />
First, a root volume for Arch Linux is created. This command assumes the current working directory is the btrfs root volume (subvolid=5), but anywhere could be used. If a different location is used, within an existing hierarchy, keep this in mind when later defining fstab and similar. Also note, that as the Arch Linux specific volume is created on a mounted (root) volume, it could be the case that the underlying stack is using (full)disk encryption.<br />
<br />
# btrfs subvolume create "arch_root"<br />
<br />
== Installation ==<br />
<br />
=== Launching the container ===<br />
<br />
The remainder of the installation will be done inside a docker container, abbreviated with ADC, Aarch Docker Container.<br />
<br />
# docker run \<br />
--env PS1="DAC(\#)[\d \T:\w]\\$ " \<br />
--interactive \<br />
--privileged \<br />
--rm \<br />
--tty \<br />
--volume "/tmp/target:/target" \<br />
"index.docker.io/library/archlinux:latest" /bin/sh<br />
<br />
=== Select the mirrors ===<br />
<br />
Packages to be installed must be downloaded from [[Mirrors|mirror servers]], which are defined in {{ic|/etc/pacman.d/mirrorlist}}. In the docker container we first install [[reflector]], which updates the mirror list by choosing 70 most recently synchronized HTTPS mirrors and sorting them by download rate. [https://gitlab.archlinux.org/archlinux/archiso/-/blob/master/configs/releng/airootfs/etc/systemd/system/reflector.service]<br />
First we have to [[install]] [[reflector]] in the docker container to be able to use it.<br />
<br />
# reflector [--country <country>] \<br />
--latest 5 \<br />
--save "/etc/pacman.d/mirrorlist" \<br />
--sort rate<br />
<br />
The higher a mirror is placed in the list, the more priority it is given when downloading a package. Ensure to inspect the file to see if it is satisfactory. If it is not, edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.<br />
<br />
This file will later be copied to the new system by ''pacstrap'', so it is worth getting right.<br />
<br />
=== Install essential packages ===<br />
<br />
Make sure that {{Pkg|arch-install-scripts}} is installed in the Docker container. Then follow [[Installation guide#Install essential packages]] to install packages into {{ic|/target}} using the {{man|8|pacstrap}} script.<br />
<br />
== Configure the system ==<br />
<br />
Follow the instructions in [[Installation guide#Configure the system]]. Replace {{ic|/mnt}} with {{ic|/target}} as appropriate.<br />
<br />
== Reboot ==<br />
<br />
Exit the docker container by typing {{ic|exit}} or pressing {{ic|Ctrl+d}}.<br />
<br />
Optionally manually unmount all the partitions with {{ic|umount -R "/target"}}: this allows noticing any "busy" partitions, and finding the cause with {{man|1|fuser}}.<br />
<br />
With a correctly setup boot loader, a reboot should now be possible into the freshly installed Arch Linux.<br />
<br />
== Post-installation ==<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Oliverhttps://wiki.archlinux.org/index.php?title=Systemd-boot&diff=343773Systemd-boot2014-11-07T20:44:59Z<p>Oliver: when following the installation wiki; installing the bootloader is the first time someone might install something. Help them along here.</p>
<hr />
<div>{{DISPLAYTITLE:gummiboot}}<br />
[[Category:Boot loaders]]<br />
[[de:Gummiboot]]<br />
[[ja:Gummiboot]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related articles end}}<br />
<br />
From [http://freedesktop.org/wiki/Software/gummiboot/ gummiboot homepage]:<br />
:''gummiboot is a simple UEFI boot manager which executes configured EFI images. The default entry is selected by a configured pattern (glob) or an on-screen menu''.<br />
<br />
It is simple to configure, but can only start EFI executables, the Linux kernel [[EFISTUB]], UEFI Shell, grub.efi, and such.<br />
<br />
{{Warning|gummiboot simply provides a boot menu for EFISTUB kernels. In case you have issues booting EFISTUB kernels like in {{Bug|33745}}, you should use a boot loader which does not use EFISTUB, like [[GRUB]], [[Syslinux]] or [[Bootloaders#ELILO|ELILO]].}}<br />
<br />
{{Note|In the entire article {{ic|$esp}} denotes the mountpoint of the [[UEFI#EFI System Partition|EFI System Partition]] aka ESP.}}<br />
<br />
== Installation ==<br />
<br />
First, make sure your are booted in UEFI mode, [[UEFI#Requirements for UEFI Variables support to work properly|your EFI variables are accessible]], your EFI System Partition is properly mounted and your kernel and initramfs are copied onto that ESP as gummiboot cannot load EFI binaries from other partitions. It is therefore strongly recommended to mount your ESP to {{ic|/boot}} if you use gummiboot.<br />
<br />
Then, install the package {{Pkg|gummiboot}} from the [[official repositories]].<br />
<br />
# pacman -S gummiboot<br />
<br />
Finally, type the following command to copy the gummiboot binary to your EFI System Partition and add gummiboot itself as the default EFI application (default boot entry) loaded by the EFI Boot Manager. If you are not booted in UEFI mode and your EFI variables are not accessible, creating the boot entry will fail. You should however still be able to boot gummiboot as it copies the binary to the default EFI binary location on your ESP ({{ic|$esp/EFI/boot/bootx64.efi}} on x64 systems) unless a non-gummiboot EFI application is already present as the same filename.<br />
<br />
# gummiboot --path=''$esp'' install<br />
<br />
=== Updating ===<br />
<br />
gummiboot assumes that your EFI System Partition is mounted on {{ic|/boot}} in which case, each time a new gummiboot version is installed, the command {{ic|1=gummiboot --path=''$esp'' update}} will be called automatically by the {{ic|post_install}} method of the install script. If your ESP is not mounted on {{ic|/boot}}, you will have to call manually that command.<br />
<br />
== Configuration ==<br />
<br />
=== Basic Configuration ===<br />
<br />
The basic configuration is kept in {{ic|$esp/loader/loader.conf}}, with just two possible configuration options:<br />
<br />
* {{ic|default}} – default entry to select (without the {{ic|.conf}} suffix); can be a wildcard like {{ic|arch-*}}<br />
<br />
* {{ic|timeout}} – menu timeout in seconds. If this is not set, the menu will only be shown when you hold the space key while booting.<br />
<br />
Example:<br />
<br />
{{hc|$esp/loader/loader.conf|<br />
default arch<br />
timeout 4<br />
}}<br />
<br />
Note that both options can be changed in the boot menu itself, which will store them as EFI variables.<br />
<br />
{{Note|If no timeout is configured, which is the default setting, and no key pressed during bootup, the default entry is executed right away.}}<br />
<br />
=== Adding boot entries ===<br />
<br />
gummiboot searches for boot menu items in {{ic|$esp/loader/entries/*.conf}} – each file found must contain exactly one boot entry. The possible options are:<br />
<br />
* {{ic|title}} – operating system name. '''Required.'''<br />
<br />
* {{ic|version}} – kernel version, shown only when multiple entries with same title exist. Optional.<br />
<br />
* {{ic|machine-id}} – machine identifier from {{ic|/etc/machine-id}}, shown only when multiple entries with same title and version exist. Optional.<br />
<br />
* {{ic|efi}} – EFI program to start, relative to your ESP ({{ic|$esp}}); e.g. {{ic|/vmlinuz-linux}}. Either this or {{ic|linux}} (see below) is '''required.'''<br />
<br />
* {{ic|options}} – Command-line options to pass to the EFI program. Optional, but you will need at least {{ic|1=initrd=''efipath''}} and {{ic|1=root=''dev''}} if booting Linux.<br />
<br />
For Linux, you can specify {{ic|linux ''path-to-vmlinuz''}} and {{ic|initrd ''path-to-initramfs''}}; this will be automatically translated to {{ic|efi ''path''}} and {{ic|1=options initrd=''path''}} – this syntax is only supported for convenience and has no differences in function. <br />
<br />
You can find your PARTUUID with {{ic|1=blkid -s PARTUUID -o value /dev/sdxx}} (/dev/sdxx should be your root partition and not $esp)<br />
<br />
An example entry for Arch Linux:<br />
<br />
{{hc|$esp/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 rw<br />
}}<br />
<br />
Please note in the example above that PARTUUID/PARTLABEL identifies a GPT partition, and differs from UUID/LABEL, which identifies a filesystem. Using the PARTUUID/PARTLABEL is advantageous because it is invariant if you reformat the partition with another filesystem or the /dev/sd* mapping changed for some reason. It is also useful if you do not have a filesystem on the partition (or use LUKS, which does not support LABELs).<br />
<br />
An example entry for encrypted root (dm-crypt with LUKS)<br />
{{hc|$esp/loader/entries/arch-encrypted.conf|2=<br />
title Arch Linux (Encrypted)<br />
linux /path/to/vmlinuz-linux<br />
options initrd=/path/to/initramfs-linux.img cryptdevice=UUID=<UUID>:luks-<UUID> root=UUID=<luks-UUID> rw<br />
}}<br />
<br />
In the encrypted example, note that the initrd is in options -- this does not appear to be discretionary at this time. Note that UUID is used for in this example. PARTUUID should be able to replace the UUID, if so desired.<br />
<br />
You can also add other EFI programs such as {{ic|\EFI\arch\grub.efi}}.<br />
<br />
{{Note|gummiboot will automatically check for "'''Windows Boot Manager'''" ({{ic|\EFI\Microsoft\Boot\Bootmgfw.efi}}), "'''EFI Shell'''" ({{ic|\shellx64.efi}}) and "'''EFI Default Loader'''" ({{ic|\EFI\Boot\bootx64.efi}}), and display entries for them if they are present, so you do not have to manually create entries for them. However it does not autodetect other EFI applications (unlike rEFInd), so for booting the kernel, manual config entries must be created as mentioned above.}}<br />
<br />
=== Add security ===<br />
<br />
You have to note that the kernel command line parameters can be edited from the gummiboot's boot manager menu (see [[#Keys]]) by pressing {{ic|e}}. This is a major security flaw since if you redefine the {{ic|1=init=}} kernel argument with {{ic|1=init=/bin/bash}} for example, this will boot your machine directly as root without any password, bypassing easily the root password that has been defined! Since gummiboot does not currently have a password feature and has no ability to prevent kernel parameters changes, you need to make sure to define a password at hardware level (UEFI/BIOS) which prevents the computer to boot if the right password has not been entered.<br />
<br />
Since security is made of several levels and physical access already breaks any security systems, maybe encrypting your disk with [[dm-crypt]] would come in handy especially if your machine is a laptop. But this is another concern not related to gummiboot.<br />
<br />
=== Support hibernation ===<br />
<br />
Please refer to that article [[Suspend and hibernate]], especially the [[Suspend and hibernate#Example for gummiboot|Example for gummiboot]].<br />
<br />
== Inside the boot menu ==<br />
<br />
=== Keys ===<br />
<br />
The following keys are used inside the menu:<br />
* {{ic|Up/Down}} - select entry<br />
* {{ic|Enter}} - boot the selected entry<br />
* {{ic|d}} - select the default entry to boot (stored in a non-volatile EFI variable)<br />
* {{ic|-/T}} - decrease the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|+/t}} - increase the timeout (stored in a non-volatile EFI variable)<br />
* {{ic|e}} - edit the kernel command line<br />
* {{ic|v}} - show the gummiboot and UEFI version<br />
* {{ic|Q}} - quit<br />
* {{ic|P}} - print the current configuration<br />
* {{ic|h/?}} - help<br />
<br />
These hotkeys will, when pressed inside the menu or during bootup, directly boot<br />
a specific entry:<br />
<br />
* {{ic|l}} - Linux<br />
* {{ic|w}} - Windows<br />
* {{ic|a}} - OS X<br />
* {{ic|s}} - EFI Shell<br />
* {{ic|1-9}} - number of entry<br />
<br />
== Troubleshooting ==<br />
<br />
=== Manual entry using efibootmgr ===<br />
<br />
If {{ic|gummiboot install}} command failed, you can create a EFI boot entry manually using {{ic|efibootmgr}} utility:<br />
<br />
# efibootmgr -c -d /dev/sdX -p Y -l /EFI/gummiboot/gummibootx64.efi -L "Gummiboot"<br />
<br />
where {{ic|/dev/sdXY}} is the EFISYS partition.<br />
<br />
=== Menu does not appear after Windows upgrade ===<br />
<br />
For example, if you upgraded from Windows 8 to Windows 8.1, and you no longer see a boot menu after the upgrade (i.e., Windows boots immediately):<br />
* Make sure Secure Boot (BIOS setting) and Fast Startup (Windows power option setting) are both disabled.<br />
* Make sure your BIOS prefers Linux Boot Manager over Windows Boot Manager (depending on your BIOS, this might appear under a BIOS setting like Hard Disk Drive Priority).<br />
<br />
== References ==<br />
<br />
* http://freedesktop.org/wiki/Software/gummiboot/</div>Oliver