https://wiki.archlinux.org/api.php?action=feedcontributions&user=Starclimber&feedformat=atomArchWiki - User contributions [en]2024-03-28T22:59:51ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:OpenVPN&diff=564876Talk:OpenVPN2019-01-26T17:53:57Z<p>Starclimber: /* Client daemon not reconnecting after suspend section */ new section</p>
<hr />
<div>== LDAP ==<br />
<br />
I'd like to propose adding an LDAP section describing how to have OpenVPN authenticate against an OpenLDAP server. This could be an optional step and does not require client certificates. [[User:Cirkit|Cirkit]] ([[User talk:Cirkit|talk]]) 00:32, 23 September 2017 (UTC)<br />
<br />
== DNS leaks ==<br />
<br />
Regarding the [[OpenVPN#Prevent leaks if VPN goes down]] section, I don't get why "DNS will not work unless running a dedicated DNS server", the ufw rules above the warning appear to allow DNS.<br />
<br />
--[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:13, 11 August 2018 (UTC)<br />
<br />
:Which rules? The Openvpn tunnel's two do, but the section is about that dropping. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:12, 30 November 2018 (UTC)<br />
<br />
== Client daemon not reconnecting after suspend section ==<br />
<br />
Is there any further knowledge about this issue? It would be valuable to include why a workaround is necessary or what causes OpenVPN to not reconnect. I stumbled upon this section when searching for a solution. I'm not very savvy with networking or debugging it, but all I know is the routing table is not reconfigured properly after wakeup. [[User:Starclimber|Starclimber]] ([[User talk:Starclimber|talk]]) 17:53, 26 January 2019 (UTC)</div>Starclimberhttps://wiki.archlinux.org/index.php?title=User_talk:Starclimber&diff=564355User talk:Starclimber2019-01-23T01:01:43Z<p>Starclimber: Created page with "A talk page. ----"</p>
<hr />
<div>A talk page.<br />
<br />
----</div>Starclimberhttps://wiki.archlinux.org/index.php?title=User:Starclimber&diff=564354User:Starclimber2019-01-23T01:00:23Z<p>Starclimber: Created page with "I have a "fiddling around with Arch Linux" hobby."</p>
<hr />
<div>I have a "fiddling around with Arch Linux" hobby.</div>Starclimberhttps://wiki.archlinux.org/index.php?title=Talk:Dm-crypt/Encrypting_an_entire_system&diff=564353Talk:Dm-crypt/Encrypting an entire system2019-01-23T00:57:46Z<p>Starclimber: /* Encrypted boot partition (GRUB) section needs revision */ Minor edits for clarity.</p>
<hr />
<div>== LUKS on LVM /tmp example ==<br />
<br />
I don't think the example config for /tmp is correct. It uses tmpfs, which ''completely bypasses the physical disks'' (other than swap), making the whole endeavor pointless. The proper solution seems to be to use the 'tmp' option in /etc/crypttab--I just set this up, and it seems to be working. It automatically creates a new ext2 filesystem with a random key on each boot. I'd update the article, but the crypttab syntax it uses doesn't even match mine, and I don't know how to translate to the new syntax. [[User:TravisE|TravisE]] ([[User talk:TravisE|talk]]) 10:27, 11 March 2014 (UTC)<br />
:You probably use in crypttab "tmp=ext2" as option? I'd say you are right anyway (and the example still works but wastes the reserved lv diskspace). Feel free to edit right away if you clarified or post the settings you use here and we adapt them. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:06, 11 March 2014 (UTC)<br />
:I updated syntax: [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_Entire_System&diff=307002&oldid=306998]<br />
:I still left the lv for it. Question to answer before removing it would be where /tmp swaps to, if required. Do you know that? <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:45, 25 March 2014 (UTC)<br />
<br />
== <s>Encrypted boot (GRUB): no need for separate partition?</s> ==<br />
<br />
Exploiting [[GRUB#LVM]], I've just tried the following scenario on VirtualBox, modified from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|Encrypted boot partition (GRUB)]]:<br />
<br />
+---------------+----------------+----------------+----------------+----------------+<br />
|ESP partition: |Volume 1: |Volume 2: |Volume 3: |Volume 4: |<br />
| | | | | |<br />
|/boot/efi |boot |root |swap |home |<br />
| | | | | |<br />
| |/dev/store/boot |/dev/store/root |/dev/store/swap |/dev/store/home |<br />
|/dev/sdaX |----------------+----------------+----------------+----------------+<br />
|'''un'''encrypted |/dev/sdaY encrypted using LVM on LUKS |<br />
+---------------+----------------+--------------------------------------------------+<br />
<br />
It works perfectly fine, including the [[Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs]] trick. The result is clearly a lot simpler and neater, and allows avoiding [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] altogether, again being able to unlock everything by entering the password only once.<br />
<br />
Can anybody think of any disadvantages, or worse, security holes? Otherwise I'd like to update the current scenario with this method.<br />
<br />
The only problem I can think of is that [[Dm-crypt/Specialties#mkinitcpio-chkcryptoboot]] needs the partition to be separate, but we can merge [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] there and leave a link from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]] as a Tip.<br />
<br />
— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:11, 29 November 2015 (UTC)<br />
<br />
:You don't even need a separate volume for /boot. It can perfectly reside on the root volume, and GRUB will be able to boot from it.<br />
:--[[User:Elijah Master|Elijah Master]] ([[User talk:Elijah Master|talk]]) 18:03, 6 December 2017 (UTC)<br />
<br />
::The section now uses a combination of LUKS and LUKS2 encrypted volumes, so simplifying the setup would require forfeiting the use of LUKS2. Example partition layout:<br />
::{{Text art|<nowiki><br />
+---------------------+----------------------+----------------------+----------------------+----------------------+<br />
| BIOS boot partition | EFI system partition | Logical volume 1 | Logical volume 2 | Logical volume 3 |<br />
| | | | | |<br />
| | /efi | / | [SWAP] | /home |<br />
| | | | | |<br />
| | | /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home |<br />
| /dev/sda1 | /dev/sda2 +----------------------+----------------------+----------------------+<br />
| unencrypted | unencrypted | /dev/sda3 encrypted using LVM on LUKS |<br />
+---------------------+----------------------+--------------------------------------------------------------------+<br />
</nowiki>}}<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:13, 23 November 2018 (UTC)<br />
<br />
:::[[dm-crypt/Encrypting an entire system#LUKS on software RAID]] and [[dm-crypt/Encrypting an entire system#Btrfs subvolumes with swap]] also use LUKS1, so I guess it's not considered an issue. If no one stops me soon, I'll remove the separate {{ic|/boot}} partition from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:21, 6 January 2019 (UTC)<br />
<br />
::::[[Special:Diff/562643|Done]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:05, 10 January 2019 (UTC)<br />
<br />
== Full disk encryption with LUKS (encrypted LVM with swap and root) ==<br />
I wasnt able to find what I need on the wiki, but this guide got me there. I hope the arch wiki could summarize step by step as this guide does.<br />
https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/<br />
<br />
[[User:Voukait|Voukait]] ([[User talk:Voukait|talk]]) 04:13, 6 May 2016 (UTC)<br />
<br />
:Wow, that's a thorough guide indeed. Nice to see someone reused the ASCII partition layout diagram (I think Kynikos sketched this LVM one:). It also links to our instructions in a number of places, which makes me wonder if the author keeps it updated in case links change. Anyhow, very thorough, yes. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:59, 6 May 2016 (UTC)<br />
<br />
::I don't remember who originally sketched that particular diagram, but everything's published under GFDL :)<br />
::To give an answer to Voukait, we don't keep step-by-step guides like that in this wiki, as they are too difficult to maintain because too many pages would duplicate content and should be continuously kept in sync.<br />
::I think a good way of getting a first grasp on some topic is indeed to go and read "aggregated" information for a specific use case on some external sites/blogs, and then come to the ArchWiki to read more up-to-date information that can be more easily adapted to other scenarios.<br />
::Anyway we should really find a place in this article where to list external links like that.<br />
::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:03, 7 May 2016 (UTC)<br />
<br />
::: Yes, why not use a regular [[Dm-crypt/Encrypting an entire system#See also]] section and use the description. For example<br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide to install [[#LVM on LUKS]] (dated: 2014/11)<br />
::: Other possibilities? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:50, 7 May 2016 (UTC)<br />
<br />
:::Actually another possibility would be to simply use [[dm-crypt#See also]]. For example <br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide referencing [[Dm-crypt/Encrypting an entire system#LVM on LUKS]] (dated: 2014/11)<br />
:::If it gets many links, they could be grouped. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:16, 7 May 2016 (UTC)<br />
<br />
::::I agree we can use [[dm-crypt#See also]] for the moment, I'll let you implement your idea, or Voukait who pointed out the link :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:06, 8 May 2016 (UTC)<br />
<br />
== Rename volume group to be more consistent with device naming ==<br />
<br />
I propose renaming 'MyVol' to 'volumegroup' (or something similar) to improve consistency with the device names (which are all lower case), and make the example more meaningful.<br />
{{Unsigned|08:13, 16 April 2018|Terry tibbles}}<br />
<br />
:I'm not against renaming it, but "volumegroup" is too generic. Also the use of uppercase letters gives a hint to the reader that using them is allowed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:32, 16 April 2018 (UTC)<br />
<br />
::What would your suggestion be? Mine would be the 'volgroup-cryptroot' layout, to keep it as close as possible to the existing examples. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 08:21, 18 April 2018 (UTC)<br />
<br />
:::I think that "volgroup" sounds too generic. Previously the article had "[[Special:Diff/423732|MyStorage]]" and "[[Special:Diff/461158|lvm]]". I'm not good at naming things, so I can't think of a good replacement.<br />
:::Actually I'm not even certain if there's a need to rename the current VG. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
::::I think it needs to change, as I've done this several times and still find it confusing. If you imagine that someone has several volume groups, it doesn't scale well (MyVol, MyVol1), and also the mix of capital and lower case letters is difficult to read. I think a system with 'vol_group-root_crypt' for encrypted devices and 'root' for the decrypted partition would be preferable. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:25, 18 April 2018 (UTC)<br />
<br />
:::::How exactly is "vol_group" better than "MyVol" in a setup with multiple VGs? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:44, 18 April 2018 (UTC)<br />
<br />
:::::I'm not going to argue with you. That's my suggestion for improving the documentation, and making it more consistent and user-friendly. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 06:37, 19 April 2018 (UTC)<br />
<br />
::::'vol_group' does not scale any better than 'MyVol'. Is there really a major difference between 'vol_group1' and 'MyVol1'? Also shouldn't the LVM names be distinguished from physical device names like sda1? One is virtual the other physical. What exactly is confusing about 'MyVol'? It's just a placeholder for what you name the volume group. Lastly, different examples use different names or pseudo-variables. Is there really a need to have the entire page consistent beyond each example? Most users will pick one example and the partitioning scheme is clearly defined at the beginning of each example. The names chosen seem trivial as they all represent the same concept of virtual groups and logical volumes. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 10:58, 19 April 2018 (UTC)<br />
<br />
:::::I think more important than the spelling here is that 'MyVol' is misleading because it's supposed to be an example name for a volume group, not a volume, so it should be at least 'MyVolGroup', 'MyVGroup' or 'MyGroup'.<br />
:::::Regarding the spelling though, I prefer the CamelCase version because then it's easier to tell group and volume apart in the /dev/mapper/group-volume path.<br />
:::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:57, 20 April 2018 (UTC)<br />
<br />
::::::From these, I'd vote for "MyVolGroup". -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:17, 20 April 2018 (UTC)<br />
<br />
::::::"MyGroup" sounds good. Perhaps even "VolGroup"? The Camel casing would imply that you are free to rename it as you please and this can also be explicitly stated. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 16:45, 20 April 2018 (UTC)<br />
<br />
:::::::I don't think this is the appropriate article to explicitly state that uppercase is allowed, that's more in the scope of the [[LVM]] article. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:56, 20 April 2018 (UTC)<br />
<br />
::::::::Right, [[LVM]] is linked within this page and that would be a more proper place. 'VolGroup00' is another idea. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 19:08, 20 April 2018 (UTC)<br />
<br />
:::::::::So I've [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_entire_system&type=revision&diff=518110&oldid=517996 replaced] all the examples with "MyVolGroup".<br />
:::::::::The other articles mentioning LVM use all kinds of example names, but at least they do have "group", "vg", or even just a "g", enough to remind that it's a volume group, not a volume, so I don't see the need to update them, does anyone?<br />
:::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:12, 21 April 2018 (UTC)<br />
<br />
::::::::::It looks good. Terry may have implied both articles using the same name when he was referring to "consistency". It is an optional possibility, but [[LVM]] could be edited to use "MyVolGroup" for all volume group names. And also editing [[LVM#Create volume group]] to say something like "See {{man|8|lvm}} for a list of valid characters for Volume Group names." -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 18:04, 21 April 2018 (UTC)<br />
<br />
:::::::::::If we want cross-article consistency, all the articles in [[LVM]]'s related box use examples of volume groups with different names. I don't have any problems if you add a reference to lvm(8). -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:41, 22 April 2018 (UTC)<br />
<br />
== /boot Needs to remain unencrypted fallacy ==<br />
<br />
I think that we should create an additional section, showing that IT IS POSSIBLE using BIOS mode to create a true full disk encryption and stop spreading this misinformation that /boot needs to remain unencrypted, like this tutorial: https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/ -- [[User:Risthel|Risthel]] ([[User talk:Risthel|talk]]) 13:57, 1 October 2018 (UTC)<br />
<br />
:You mean https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29 ? And you don’t need BIOS mode. You can even use SecureBoot to sign your GRUB uefi with your own keys. [[User:Archange|Archange]] ([[User talk:Archange|talk]]) 09:00, 2 October 2018 (UTC)<br />
<br />
:Your linked setup will still not be a "''true full disk encryption''". The GRUB in [[Partitioning#Master Boot Record (bootstrap code)|MBR]] and MBR-gap or BIOS boot partition will remain unencrypted. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:23, 2 October 2018 (UTC)<br />
<br />
::2 Things here: 1 - This Encrypted boot partition with EFI will still need an unencrypted EFI(thus, susceptible to EFI malware/tampering) ; 2 - SecureBoot customization is hardware dependent. Some machines will not allow you to inject your own keys, having to rely on Microsoft signing or disabling it at all. When i say that it IS possible using BIOS, i'm not saying its not possible through EFI. But it is better showing the way /boot CAN be encrypted on BIOS mode instead of making this lie go further that /boot NEEDS do be unencrypted on BIOS environment :) . I'm also aware of MBR not being encrypted, and maybe a "hook" could be developed where mkinitcpio could check grub's hash with a file stored at /boot or root partition and alert the user... but that is offtopic and should be part of other wiki :) -- [[User:Risthel|Risthel]] ([[User talk:Risthel|talk]]) 18:01, 2 October 2018 (UTC)<br />
<br />
::: But unencrypted MBR is just the BIOS equivalent to unencrypted EFI. So what your saying makes no sense. Just like you could check grub hash, you could check grub efi hash. And they are already software for that. The easiest and most secure (tells you before entering your password) is still using SecureBoot/TPM, or using an EFI/grub on a USB device. Or both. [[User:Archange|Archange]] ([[User talk:Archange|talk]]) 18:32, 2 October 2018 (UTC)<br />
<br />
:::: Agree with you. To make it complete in BIOS and minimize evil-maid attacks trustedgrub(aur)[https://aur.archlinux.org/packages/trustedgrub2/|trustedgrub(aur)] should be used. But again, it's still a lie to say at the wiki that "/boot must be unencrypted" - https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Preparing_the_boot_partition_2<br />
<br />
:::::You do realize that [[dm-crypt/Encrypting an entire system#Preparing_the_boot_partition_2]] is in the [[dm-crypt/Encrypting an entire system#LVM on LUKS]] scenario? Encrypted {{ic|/boot}} is described separately in [[dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:57, 3 October 2018 (UTC)<br />
<br />
== Why the ASCII diagrams? ==<br />
<br />
Why do you people make those ASCII diagrams for this page? Would using those nice Unicode symbols (╠═╬═╣║) not be better? And using MediaWiki tables even better?<br />
<br />
BTW, here's a nice Web site which can generate all of those formats of table descriptions: https://www.tablesgenerator.com/mediawiki_tables [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 13:04, 6 January 2019 (UTC)<br />
<br />
:AFAIK tables are not used due to accessibility issues. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:24, 6 January 2019 (UTC)<br />
<br />
:Some diagrams on this page have multiple different vertical alignments in the same cell. Good luck realizing that with HTML. Also we prefer our wikicode to be editable without external tools and mutlirows / multicols are very cumbersome to work with by hand. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 19:50, 7 January 2019 (UTC)<br />
<br />
Regarding the attempted fixing of ASCII table alignment failure: I realize that your revertion of my fixes (conditionally speaking) aligned the rows assuming a fixed-width typeface, but on Chromium 71.0.3578.98 (and whatever versions of relevant libraries), a proportional typeface is used. Namely, "ef" takes up the same space as " " does, I think. I think the correct term for that is "ligature".<br />
<br />
Anyway, I think this just shows those character-based tables should be abandoned in favor of using MediaWiki tables. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 18:02, 7 January 2019 (UTC)<br />
<br />
:Your fonts must be misconfigured it looks fine in my Chromium. Do the following lines have the same length for you?<br />
<pre>ffffffffff<br />
WWWWWWWWWW</pre><br />
:Does the right side of [https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_pre] look monospace to you? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 19:32, 7 January 2019 (UTC)<br />
<br />
:: The 10 'f' characters are combined into 5 pairs of ligatured "ff", one ligature takes takes as much space as one 'W'. So the 10 'f' characters take as much space and line up with 5 'W' characters.<br />
:: That tryit text you linked is monospace except that "fi" in "fixed" are joined in a ligature. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 21:43, 7 January 2019 (UTC)<br />
<br />
:: Here is a Archlinux BBS thread which explains the issue if anybody is curious: [https://bbs.archlinux.org/viewtopic.php?id=238832], I also have "Nimbus Mono PS" as the default monospace font, and it supports ligatures.<br />
::This explains how to try to disable the ligatures: [[Font_configuration/Examples#Disable_ligatures_for_monospaced_fonts]]<br />
:: Even if it is possible to configure Chromium to disable ligatures (have not checked), I still think this is a big argument against using ASCII art in the wiki. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 22:35, 7 January 2019 (UTC)<br />
<br />
::: AFAIK we used the current ASCII form, because the same format was used in related (LVM,RAID) articles and was the default output of http://asciiflow.com/ at the same time.<br />
::: When trying alternatives a good way to check accessibility is if you try that your example, e.g.<br />
::: {{ic|<nowiki>elinks https://wiki.archlinux.org/index.php/Talk:Dm-crypt/Encrypting_an_entire_system#Why_the_ASCII_diagrams?</nowiki>}}<br />
::: looks like an improvement to the existing<br />
::: {{ic|<nowiki>elinks https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Preparing_the_disk</nowiki>}}<br />
::: Consider users install purely in TTY & ''elinks'' is included in the ISO. <br />
::: --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:36, 11 January 2019 (UTC)<br />
<br />
:::: So that is what you guys mean by accessibility! OK, then, but I can not figure out if you are saying that we should use Unicode for tables or only ASCII ...? [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 02:16, 13 January 2019 (UTC)<br />
<br />
:::::I don't think we should switch to Unicode just for the sake of using fancy symbols. With Unicode characters there is a greater chance that they are not supported by a font or break the monospace grid in a browser. Unicode is alright if ASCII is not expressive enough (e.g. the diagrams in [[Disk encryption]]) but in this article we just have tables for which {{ic|+-{{!}}}} suffice. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 06:06, 13 January 2019 (UTC)<br />
<br />
::::::I agree. Of course, it is nice to use the available means to present the content well, but keep in mind to balance readability gains with the extra effort to create/maintain. Neven, if you want to propose Unicode-border tables generally, [[Help_talk:Style]] would be the place for that (along with tools to mention in [[Help:Style#Non-pertinent content]]). Ok? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 15:42, 19 January 2019 (UTC)<br />
<br />
== Using UUIDs for device maps? ==<br />
<br />
What is the point of using UUIDs to access device mapper devices (e.g., LVM)? Seems unnecessary. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 14:53, 6 January 2019 (UTC)<br />
<br />
:The only useless use of UUID I can find is the {{ic|cryptdevice}} in [[dm-crypt/Encrypting an entire system#Configuring_the_boot_loader_3]] (in the LUKS on LVM scenario). That one was changed in [[Special:Diff/551821]], presumably to be consistent with the {{ic|rd.luks}} kernel parameters, which have the stupid limitation of only supporting UUIDs. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:20, 6 January 2019 (UTC)<br />
<br />
:: +1 to keeping it due to {{ic|rd.luks}} example. Also, some years prior to sd-encrypt a lot of users of multiple DMs (e.g. raid/lvm or dm-crypt/lvm <--culprit;) had race conditions on device activation at boot. Sometime the links to [[Persistent block device naming]] were added, but the nomenclatura kept to keep it readable for the examples. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:11, 11 January 2019 (UTC)<br />
:: Btw, {{Bug|60907}} for ''sd-encrypt'' is similar in effect to what happened back then with ''encrypt''. Odd. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:53, 12 January 2019 (UTC)<br />
<br />
== Can we rename "Plain dm-crypt" to "LVM on plain dm-crypt" ==<br />
<br />
This is because I want to add "GPT on plain dm-crypt". Note that this proposal is different from the change from before because of the explicit "plain" in the section title. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 01:20, 17 January 2019 (UTC)<br />
<br />
:I see, can you make a very quick draft to understand better what you're proposing? What are advantages and disadvantages compared to the LVM method? If there isn't much difference perhaps it would be better to just add it as a variation Tip in the plain dm-crypt scenario? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:31, 18 January 2019 (UTC)<br />
<br />
:: The essential differences of using GPT instead of LVM are:<br />
<br />
:: * Advantage: No need for userspace daemons (besides possibly udev, which is running constantly on almost all Archlinux machines anyways, I presume). Speculation: this means faster bootup.<br />
<br />
:: * Disadvantage: There is currently no support for detecting and mapping GPT partitions that reside on device maps, like there is for LVM volumes. Thus the user would need to set up an Udev rule or just a command in a mkinitcpio hook to detect and map the GPT partitions as device mapper maps. Kpartx or partprobe can be used for that. (An alternative to using device mapper would be to use losetup to access the partitions as loopback devices, but I think that would be less performant.)<br />
<br />
:: Another, small, change from the "Plain dm-crypt" section that I want to make in the new section is using only one removable flash drive instead of two. So the flash drive would have two partitions. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 23:54, 18 January 2019 (UTC)<br />
<br />
::: After reading the relevant mailing list thread, I came to the conclusion that the 'encrypted GPT use case' targets situation when '''1)''' plain dm-crypt is desired for deniable encryption reasoning and LUKS header is avoided (note, this could be partially archived by detached LUKS header, personally I like plain dm-crypt, but many will object that deniable encryption of 500+GB space is nonsense) '''2)''' user wants to encrypt several 'partitions' (in abstract sense) at once (without having 3+ separate partitions with different passwords) but does not want to use LVM for some reason (if LVM is avoided because of additional layer costs - this argument is weak, because what is the evidence that these costs are significant? how much does LVM reduce IO read/write? how much does it slow boot? If not costs, then what is the reason which makes LVM an unaccepted alternative?) '''3)''' user wants to use filesystem which does not support 'logical' partitions, like btrfs, OR, if such system cannot have swap space. For example, a user wanting only ext4 partitions, or user wanting both btrfs AND swap partition (for example, he likes compiling Chrome browser). I may be wrong here, but propose that such type of information should be included. --[[User:Mxfm|Mxfm]] ([[User talk:Mxfm|talk]]) 12:47, 19 January 2019 (UTC)<br />
<br />
::::The "partition table on plain dm-crypt or LUKS" scenario would involve modifying/creating mkinitcpio hooks. As such I do not think it could be placed in [[dm-crypt/Encrypting an entire system]]. The only place for such a setup would be the same place where the "[[dm-crypt/Specialties#Encrypted system using a detached LUKS header|Encrypted system using a detached LUKS header]]" scenario is - [[dm-crypt/Specialties]] (aka ''dm-crypt/Weird and unusual setups''). -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:58, 19 January 2019 (UTC)<br />
<br />
::::: Why would mkinitcpio hooks cut be the cut off point for what makes it in [[dm-crypt/Encrypting an entire system]]? That makes no sense. This proposed section would logically appear right beside the current "Plain dm-crypt" section, because it also uses "Plain dm-crypt", unlike the rest of the page which uses LUKS. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 13:15, 19 January 2019 (UTC)<br />
<br />
::::::None of the other scenarios in [[dm-crypt/Encrypting an entire system]] require creating custom hooks. I don't think we should add such complex setups to this page. Regardless of that, I support renaming the "Plain dm-crypt" scenario to "LVM on plain dm-crypt" -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:44, 19 January 2019 (UTC)<br />
<br />
::::::: Is creating a hook and adding it to mkinitcpio.conf really such a hassle? The page already suggests using some configuration files, like fstab and crypttab; so I do not see the rise in complexity from using hooks. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 13:50, 19 January 2019 (UTC)<br />
<br />
::::::::It might be, but I guess that depends on how complex it is. If the hook or udev rule could be packaged (even in AUR), then that would be even better. To clarify, I'm not trying to dissuade you, but without a ready draft it's hard for me to evaluate the scenario. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:01, 19 January 2019 (UTC)<br />
<br />
::::::::: Just a single command is really necessary: either '''kpartx -a disk''' or '''partprobe disk'''. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 14:11, 19 January 2019 (UTC)<br />
<br />
:::::::::: If you look over the different scenarios on this scenario page, you won't find custom hooks/udev rules/etc. for now, because (1) they are meant as installation examples with the tools on the ISO, i.e. to keep focus. (2) Maintainability of non-standard tools/hooks is a general issue. <br />
:::::::::: @Neven: reduction to one flash drive is mentioned in the first tip already. I'm against explicitly using a single flash, because it contravenes reasons to use plain dm-crypt in the first place. Remember boot loader configuration in the example gives away the location of a key-file, hence, if you have it on one flash ..<br />
:::::::::: I'm +1 to nl6720's suggestion to add the custom hooks to a new subsection in [[dm-crypt/Specialties]]; there is more room to explain pros&cons of your new kpartx method. ('''mod note''' seems useful to continue this branch at the end of the next branch) --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 14:42, 19 January 2019 (UTC)<br />
<br />
:::::::::::I see this is an interesting exercise, but without a clear technical definition of its benefits (which should have greater extent than other variations such as detached headers), its use cases would practically overlap those for the traditional LVM method, also in lack of scientific benchmarks that prove a noticeable performance improvement, so +1 to add this to the Specialties page and link to it from a Tip as a variation to the plain dm-crypt scenario.<br />
:::::::::::Even if this method was considered distinct enough to be given a separate scenario (which I repeat I'm against at the moment), I think the hook should still be put in /Specialties and linked from the scenario.<br />
:::::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:40, 20 January 2019 (UTC)<br />
<br />
Maybe it would be even better to replace "dm-crypt" with "encryption" in the title, or maybe something like "LVM/GPT behind a ciphertext" would be even better. That is because dm-crypt is not a format, but rather just a method in the kernel of doing encryption without any header or metadata. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 10:18, 17 January 2019 (UTC)<br />
<br />
:"Plain dm-crypt" is an expression that is used all over {{man|8|cryptsetup}}, maybe you're kind of right in ideal terms, but often technical jargon relies on conventional idioms that, despite not being literally correct, do a better job at conveying the intended meanings because of their widespread traditional usage, compared to perhaps more accurate but less recognized/able phrasings. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:31, 18 January 2019 (UTC)<br />
<br />
: Now that I think about it, I only thought of this because I forgot that this page was about dm-crypt instead of about disk encryption in general. So, the parent paragraph can just be ignored. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 23:57, 18 January 2019 (UTC)<br />
<br />
: Can you explain your proposal better? What exactly you want to change? Without clarifications, your proposal is controversial, because you essentially propose rename 'plain dm-crypt' to 'LVM on plain dm-crypt' which is obviously false. These are two different use cases and hiding one of them behind the other is incorrect. For example, I use plain dm-crypt, but do not use LVM. If you propose to rename entire page, than it seems uresonable, because in current [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_entire_system&type=revision&diff=563591&oldid=563545 form] the page does not contain information ''only'' about LVM, it has sections regarding encrypted boot and swap. If you propose to rename specific section 'Plain dm-crypt', then it is also incorrect because that section has nothing to do with LVM. It looks like you have implicit assumption (from your experience) that there are only two use cases - LVM on plain dm-crypt and GPT on plain dm-crypt (and there is no plain dm-crypt without LVM/GPT use case). Contrary to this view, in my opinion the situation is completely different. The majority use cases are LUKS (possibly with LVM) and plain dm-crypt (possibly with LVM). The encrypted GPT use case is a new one which was covered in recent [https://lists.archlinux.org/pipermail/arch-general/2019-January/045968.html mailing list thread] and could be supported in future. --[[User:Mxfm|Mxfm]] ([[User talk:Mxfm|talk]]) 12:25, 19 January 2019 (UTC)<br />
<br />
:: You are being kind of confusing here with your expression, so it seems to me that you are saying a lot of irrelevant or obviously false stuff, but I will try to respond anyway:<br />
::* I am proposing to rename the "Plain dm-crypt" section, not the entire page.<br />
::* The section in question is about LVM on plain dm-crypt, thus the proposed name. I can not fathom why would you say it is not about LVM.<br />
::* I did not understand the stuff at the end at all. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 13:11, 19 January 2019 (UTC)<br />
<br />
::: I think Mxfm simply overread that you already dismissed the rename idea, and at the end Mxfm gave a first-hand example of why we can't feature full-length example scenarios for all possibilities. <br />
::: Still, to me it is out of question that we should find a place where your approach can be explained adequately & currently I think the above suggestion to add to [[dm-crypt/Specialties]] and crosslinking it is best. Once that part is in place and linked to the existing plain dm-crypt example in this page, it is easier to decide if it makes sense to add a totally new scenario for it, or crosslinking from/to the plain dm-crypt scenario suffices. Thoughts? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 14:42, 19 January 2019 (UTC)<br />
<br />
== Encrypted boot partition (GRUB) section needs revision ==<br />
<br />
A few weeks ago, I used the guide here for setting up LVM on LUKS with an encrypted boot partition. There are two parts of this section that I think need revision. First, under '''Configuring GRUB''', running ''grub-install'' should been done after editing ''/etc/default/grub'', otherwise errors come up involving the ''GRUB_ENABLE_CRYPTODISK'' line. Second, running ''grub-mkconfig'' in the last step will hang for a while and fail. The supposed reason (updates with LVM2) and a workaround is proposed in [https://bbs.archlinux.org/viewtopic.php?id=242594 this Arch Linux forum post] from a month ago. [[User:Starclimber|Starclimber]] ([[User talk:Starclimber|talk]]) 00:55, 23 January 2019 (UTC)</div>Starclimberhttps://wiki.archlinux.org/index.php?title=Talk:Dm-crypt/Encrypting_an_entire_system&diff=564352Talk:Dm-crypt/Encrypting an entire system2019-01-23T00:55:46Z<p>Starclimber: /* Encrypted boot partition (GRUB) section needs revision */ new section</p>
<hr />
<div>== LUKS on LVM /tmp example ==<br />
<br />
I don't think the example config for /tmp is correct. It uses tmpfs, which ''completely bypasses the physical disks'' (other than swap), making the whole endeavor pointless. The proper solution seems to be to use the 'tmp' option in /etc/crypttab--I just set this up, and it seems to be working. It automatically creates a new ext2 filesystem with a random key on each boot. I'd update the article, but the crypttab syntax it uses doesn't even match mine, and I don't know how to translate to the new syntax. [[User:TravisE|TravisE]] ([[User talk:TravisE|talk]]) 10:27, 11 March 2014 (UTC)<br />
:You probably use in crypttab "tmp=ext2" as option? I'd say you are right anyway (and the example still works but wastes the reserved lv diskspace). Feel free to edit right away if you clarified or post the settings you use here and we adapt them. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:06, 11 March 2014 (UTC)<br />
:I updated syntax: [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_Entire_System&diff=307002&oldid=306998]<br />
:I still left the lv for it. Question to answer before removing it would be where /tmp swaps to, if required. Do you know that? <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:45, 25 March 2014 (UTC)<br />
<br />
== <s>Encrypted boot (GRUB): no need for separate partition?</s> ==<br />
<br />
Exploiting [[GRUB#LVM]], I've just tried the following scenario on VirtualBox, modified from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|Encrypted boot partition (GRUB)]]:<br />
<br />
+---------------+----------------+----------------+----------------+----------------+<br />
|ESP partition: |Volume 1: |Volume 2: |Volume 3: |Volume 4: |<br />
| | | | | |<br />
|/boot/efi |boot |root |swap |home |<br />
| | | | | |<br />
| |/dev/store/boot |/dev/store/root |/dev/store/swap |/dev/store/home |<br />
|/dev/sdaX |----------------+----------------+----------------+----------------+<br />
|'''un'''encrypted |/dev/sdaY encrypted using LVM on LUKS |<br />
+---------------+----------------+--------------------------------------------------+<br />
<br />
It works perfectly fine, including the [[Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs]] trick. The result is clearly a lot simpler and neater, and allows avoiding [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] altogether, again being able to unlock everything by entering the password only once.<br />
<br />
Can anybody think of any disadvantages, or worse, security holes? Otherwise I'd like to update the current scenario with this method.<br />
<br />
The only problem I can think of is that [[Dm-crypt/Specialties#mkinitcpio-chkcryptoboot]] needs the partition to be separate, but we can merge [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] there and leave a link from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]] as a Tip.<br />
<br />
— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:11, 29 November 2015 (UTC)<br />
<br />
:You don't even need a separate volume for /boot. It can perfectly reside on the root volume, and GRUB will be able to boot from it.<br />
:--[[User:Elijah Master|Elijah Master]] ([[User talk:Elijah Master|talk]]) 18:03, 6 December 2017 (UTC)<br />
<br />
::The section now uses a combination of LUKS and LUKS2 encrypted volumes, so simplifying the setup would require forfeiting the use of LUKS2. Example partition layout:<br />
::{{Text art|<nowiki><br />
+---------------------+----------------------+----------------------+----------------------+----------------------+<br />
| BIOS boot partition | EFI system partition | Logical volume 1 | Logical volume 2 | Logical volume 3 |<br />
| | | | | |<br />
| | /efi | / | [SWAP] | /home |<br />
| | | | | |<br />
| | | /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home |<br />
| /dev/sda1 | /dev/sda2 +----------------------+----------------------+----------------------+<br />
| unencrypted | unencrypted | /dev/sda3 encrypted using LVM on LUKS |<br />
+---------------------+----------------------+--------------------------------------------------------------------+<br />
</nowiki>}}<br />
:: -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:13, 23 November 2018 (UTC)<br />
<br />
:::[[dm-crypt/Encrypting an entire system#LUKS on software RAID]] and [[dm-crypt/Encrypting an entire system#Btrfs subvolumes with swap]] also use LUKS1, so I guess it's not considered an issue. If no one stops me soon, I'll remove the separate {{ic|/boot}} partition from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:21, 6 January 2019 (UTC)<br />
<br />
::::[[Special:Diff/562643|Done]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:05, 10 January 2019 (UTC)<br />
<br />
== Full disk encryption with LUKS (encrypted LVM with swap and root) ==<br />
I wasnt able to find what I need on the wiki, but this guide got me there. I hope the arch wiki could summarize step by step as this guide does.<br />
https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/<br />
<br />
[[User:Voukait|Voukait]] ([[User talk:Voukait|talk]]) 04:13, 6 May 2016 (UTC)<br />
<br />
:Wow, that's a thorough guide indeed. Nice to see someone reused the ASCII partition layout diagram (I think Kynikos sketched this LVM one:). It also links to our instructions in a number of places, which makes me wonder if the author keeps it updated in case links change. Anyhow, very thorough, yes. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:59, 6 May 2016 (UTC)<br />
<br />
::I don't remember who originally sketched that particular diagram, but everything's published under GFDL :)<br />
::To give an answer to Voukait, we don't keep step-by-step guides like that in this wiki, as they are too difficult to maintain because too many pages would duplicate content and should be continuously kept in sync.<br />
::I think a good way of getting a first grasp on some topic is indeed to go and read "aggregated" information for a specific use case on some external sites/blogs, and then come to the ArchWiki to read more up-to-date information that can be more easily adapted to other scenarios.<br />
::Anyway we should really find a place in this article where to list external links like that.<br />
::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:03, 7 May 2016 (UTC)<br />
<br />
::: Yes, why not use a regular [[Dm-crypt/Encrypting an entire system#See also]] section and use the description. For example<br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide to install [[#LVM on LUKS]] (dated: 2014/11)<br />
::: Other possibilities? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:50, 7 May 2016 (UTC)<br />
<br />
:::Actually another possibility would be to simply use [[dm-crypt#See also]]. For example <br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide referencing [[Dm-crypt/Encrypting an entire system#LVM on LUKS]] (dated: 2014/11)<br />
:::If it gets many links, they could be grouped. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:16, 7 May 2016 (UTC)<br />
<br />
::::I agree we can use [[dm-crypt#See also]] for the moment, I'll let you implement your idea, or Voukait who pointed out the link :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:06, 8 May 2016 (UTC)<br />
<br />
== Rename volume group to be more consistent with device naming ==<br />
<br />
I propose renaming 'MyVol' to 'volumegroup' (or something similar) to improve consistency with the device names (which are all lower case), and make the example more meaningful.<br />
{{Unsigned|08:13, 16 April 2018|Terry tibbles}}<br />
<br />
:I'm not against renaming it, but "volumegroup" is too generic. Also the use of uppercase letters gives a hint to the reader that using them is allowed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:32, 16 April 2018 (UTC)<br />
<br />
::What would your suggestion be? Mine would be the 'volgroup-cryptroot' layout, to keep it as close as possible to the existing examples. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 08:21, 18 April 2018 (UTC)<br />
<br />
:::I think that "volgroup" sounds too generic. Previously the article had "[[Special:Diff/423732|MyStorage]]" and "[[Special:Diff/461158|lvm]]". I'm not good at naming things, so I can't think of a good replacement.<br />
:::Actually I'm not even certain if there's a need to rename the current VG. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
::::I think it needs to change, as I've done this several times and still find it confusing. If you imagine that someone has several volume groups, it doesn't scale well (MyVol, MyVol1), and also the mix of capital and lower case letters is difficult to read. I think a system with 'vol_group-root_crypt' for encrypted devices and 'root' for the decrypted partition would be preferable. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:25, 18 April 2018 (UTC)<br />
<br />
:::::How exactly is "vol_group" better than "MyVol" in a setup with multiple VGs? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:44, 18 April 2018 (UTC)<br />
<br />
:::::I'm not going to argue with you. That's my suggestion for improving the documentation, and making it more consistent and user-friendly. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 06:37, 19 April 2018 (UTC)<br />
<br />
::::'vol_group' does not scale any better than 'MyVol'. Is there really a major difference between 'vol_group1' and 'MyVol1'? Also shouldn't the LVM names be distinguished from physical device names like sda1? One is virtual the other physical. What exactly is confusing about 'MyVol'? It's just a placeholder for what you name the volume group. Lastly, different examples use different names or pseudo-variables. Is there really a need to have the entire page consistent beyond each example? Most users will pick one example and the partitioning scheme is clearly defined at the beginning of each example. The names chosen seem trivial as they all represent the same concept of virtual groups and logical volumes. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 10:58, 19 April 2018 (UTC)<br />
<br />
:::::I think more important than the spelling here is that 'MyVol' is misleading because it's supposed to be an example name for a volume group, not a volume, so it should be at least 'MyVolGroup', 'MyVGroup' or 'MyGroup'.<br />
:::::Regarding the spelling though, I prefer the CamelCase version because then it's easier to tell group and volume apart in the /dev/mapper/group-volume path.<br />
:::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:57, 20 April 2018 (UTC)<br />
<br />
::::::From these, I'd vote for "MyVolGroup". -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:17, 20 April 2018 (UTC)<br />
<br />
::::::"MyGroup" sounds good. Perhaps even "VolGroup"? The Camel casing would imply that you are free to rename it as you please and this can also be explicitly stated. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 16:45, 20 April 2018 (UTC)<br />
<br />
:::::::I don't think this is the appropriate article to explicitly state that uppercase is allowed, that's more in the scope of the [[LVM]] article. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:56, 20 April 2018 (UTC)<br />
<br />
::::::::Right, [[LVM]] is linked within this page and that would be a more proper place. 'VolGroup00' is another idea. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 19:08, 20 April 2018 (UTC)<br />
<br />
:::::::::So I've [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_entire_system&type=revision&diff=518110&oldid=517996 replaced] all the examples with "MyVolGroup".<br />
:::::::::The other articles mentioning LVM use all kinds of example names, but at least they do have "group", "vg", or even just a "g", enough to remind that it's a volume group, not a volume, so I don't see the need to update them, does anyone?<br />
:::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:12, 21 April 2018 (UTC)<br />
<br />
::::::::::It looks good. Terry may have implied both articles using the same name when he was referring to "consistency". It is an optional possibility, but [[LVM]] could be edited to use "MyVolGroup" for all volume group names. And also editing [[LVM#Create volume group]] to say something like "See {{man|8|lvm}} for a list of valid characters for Volume Group names." -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 18:04, 21 April 2018 (UTC)<br />
<br />
:::::::::::If we want cross-article consistency, all the articles in [[LVM]]'s related box use examples of volume groups with different names. I don't have any problems if you add a reference to lvm(8). -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:41, 22 April 2018 (UTC)<br />
<br />
== /boot Needs to remain unencrypted fallacy ==<br />
<br />
I think that we should create an additional section, showing that IT IS POSSIBLE using BIOS mode to create a true full disk encryption and stop spreading this misinformation that /boot needs to remain unencrypted, like this tutorial: https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/ -- [[User:Risthel|Risthel]] ([[User talk:Risthel|talk]]) 13:57, 1 October 2018 (UTC)<br />
<br />
:You mean https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Encrypted_boot_partition_.28GRUB.29 ? And you don’t need BIOS mode. You can even use SecureBoot to sign your GRUB uefi with your own keys. [[User:Archange|Archange]] ([[User talk:Archange|talk]]) 09:00, 2 October 2018 (UTC)<br />
<br />
:Your linked setup will still not be a "''true full disk encryption''". The GRUB in [[Partitioning#Master Boot Record (bootstrap code)|MBR]] and MBR-gap or BIOS boot partition will remain unencrypted. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:23, 2 October 2018 (UTC)<br />
<br />
::2 Things here: 1 - This Encrypted boot partition with EFI will still need an unencrypted EFI(thus, susceptible to EFI malware/tampering) ; 2 - SecureBoot customization is hardware dependent. Some machines will not allow you to inject your own keys, having to rely on Microsoft signing or disabling it at all. When i say that it IS possible using BIOS, i'm not saying its not possible through EFI. But it is better showing the way /boot CAN be encrypted on BIOS mode instead of making this lie go further that /boot NEEDS do be unencrypted on BIOS environment :) . I'm also aware of MBR not being encrypted, and maybe a "hook" could be developed where mkinitcpio could check grub's hash with a file stored at /boot or root partition and alert the user... but that is offtopic and should be part of other wiki :) -- [[User:Risthel|Risthel]] ([[User talk:Risthel|talk]]) 18:01, 2 October 2018 (UTC)<br />
<br />
::: But unencrypted MBR is just the BIOS equivalent to unencrypted EFI. So what your saying makes no sense. Just like you could check grub hash, you could check grub efi hash. And they are already software for that. The easiest and most secure (tells you before entering your password) is still using SecureBoot/TPM, or using an EFI/grub on a USB device. Or both. [[User:Archange|Archange]] ([[User talk:Archange|talk]]) 18:32, 2 October 2018 (UTC)<br />
<br />
:::: Agree with you. To make it complete in BIOS and minimize evil-maid attacks trustedgrub(aur)[https://aur.archlinux.org/packages/trustedgrub2/|trustedgrub(aur)] should be used. But again, it's still a lie to say at the wiki that "/boot must be unencrypted" - https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Preparing_the_boot_partition_2<br />
<br />
:::::You do realize that [[dm-crypt/Encrypting an entire system#Preparing_the_boot_partition_2]] is in the [[dm-crypt/Encrypting an entire system#LVM on LUKS]] scenario? Encrypted {{ic|/boot}} is described separately in [[dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 05:57, 3 October 2018 (UTC)<br />
<br />
== Why the ASCII diagrams? ==<br />
<br />
Why do you people make those ASCII diagrams for this page? Would using those nice Unicode symbols (╠═╬═╣║) not be better? And using MediaWiki tables even better?<br />
<br />
BTW, here's a nice Web site which can generate all of those formats of table descriptions: https://www.tablesgenerator.com/mediawiki_tables [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 13:04, 6 January 2019 (UTC)<br />
<br />
:AFAIK tables are not used due to accessibility issues. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:24, 6 January 2019 (UTC)<br />
<br />
:Some diagrams on this page have multiple different vertical alignments in the same cell. Good luck realizing that with HTML. Also we prefer our wikicode to be editable without external tools and mutlirows / multicols are very cumbersome to work with by hand. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 19:50, 7 January 2019 (UTC)<br />
<br />
Regarding the attempted fixing of ASCII table alignment failure: I realize that your revertion of my fixes (conditionally speaking) aligned the rows assuming a fixed-width typeface, but on Chromium 71.0.3578.98 (and whatever versions of relevant libraries), a proportional typeface is used. Namely, "ef" takes up the same space as " " does, I think. I think the correct term for that is "ligature".<br />
<br />
Anyway, I think this just shows those character-based tables should be abandoned in favor of using MediaWiki tables. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 18:02, 7 January 2019 (UTC)<br />
<br />
:Your fonts must be misconfigured it looks fine in my Chromium. Do the following lines have the same length for you?<br />
<pre>ffffffffff<br />
WWWWWWWWWW</pre><br />
:Does the right side of [https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_pre] look monospace to you? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 19:32, 7 January 2019 (UTC)<br />
<br />
:: The 10 'f' characters are combined into 5 pairs of ligatured "ff", one ligature takes takes as much space as one 'W'. So the 10 'f' characters take as much space and line up with 5 'W' characters.<br />
:: That tryit text you linked is monospace except that "fi" in "fixed" are joined in a ligature. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 21:43, 7 January 2019 (UTC)<br />
<br />
:: Here is a Archlinux BBS thread which explains the issue if anybody is curious: [https://bbs.archlinux.org/viewtopic.php?id=238832], I also have "Nimbus Mono PS" as the default monospace font, and it supports ligatures.<br />
::This explains how to try to disable the ligatures: [[Font_configuration/Examples#Disable_ligatures_for_monospaced_fonts]]<br />
:: Even if it is possible to configure Chromium to disable ligatures (have not checked), I still think this is a big argument against using ASCII art in the wiki. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 22:35, 7 January 2019 (UTC)<br />
<br />
::: AFAIK we used the current ASCII form, because the same format was used in related (LVM,RAID) articles and was the default output of http://asciiflow.com/ at the same time.<br />
::: When trying alternatives a good way to check accessibility is if you try that your example, e.g.<br />
::: {{ic|<nowiki>elinks https://wiki.archlinux.org/index.php/Talk:Dm-crypt/Encrypting_an_entire_system#Why_the_ASCII_diagrams?</nowiki>}}<br />
::: looks like an improvement to the existing<br />
::: {{ic|<nowiki>elinks https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Preparing_the_disk</nowiki>}}<br />
::: Consider users install purely in TTY & ''elinks'' is included in the ISO. <br />
::: --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:36, 11 January 2019 (UTC)<br />
<br />
:::: So that is what you guys mean by accessibility! OK, then, but I can not figure out if you are saying that we should use Unicode for tables or only ASCII ...? [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 02:16, 13 January 2019 (UTC)<br />
<br />
:::::I don't think we should switch to Unicode just for the sake of using fancy symbols. With Unicode characters there is a greater chance that they are not supported by a font or break the monospace grid in a browser. Unicode is alright if ASCII is not expressive enough (e.g. the diagrams in [[Disk encryption]]) but in this article we just have tables for which {{ic|+-{{!}}}} suffice. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 06:06, 13 January 2019 (UTC)<br />
<br />
::::::I agree. Of course, it is nice to use the available means to present the content well, but keep in mind to balance readability gains with the extra effort to create/maintain. Neven, if you want to propose Unicode-border tables generally, [[Help_talk:Style]] would be the place for that (along with tools to mention in [[Help:Style#Non-pertinent content]]). Ok? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 15:42, 19 January 2019 (UTC)<br />
<br />
== Using UUIDs for device maps? ==<br />
<br />
What is the point of using UUIDs to access device mapper devices (e.g., LVM)? Seems unnecessary. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 14:53, 6 January 2019 (UTC)<br />
<br />
:The only useless use of UUID I can find is the {{ic|cryptdevice}} in [[dm-crypt/Encrypting an entire system#Configuring_the_boot_loader_3]] (in the LUKS on LVM scenario). That one was changed in [[Special:Diff/551821]], presumably to be consistent with the {{ic|rd.luks}} kernel parameters, which have the stupid limitation of only supporting UUIDs. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:20, 6 January 2019 (UTC)<br />
<br />
:: +1 to keeping it due to {{ic|rd.luks}} example. Also, some years prior to sd-encrypt a lot of users of multiple DMs (e.g. raid/lvm or dm-crypt/lvm <--culprit;) had race conditions on device activation at boot. Sometime the links to [[Persistent block device naming]] were added, but the nomenclatura kept to keep it readable for the examples. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:11, 11 January 2019 (UTC)<br />
:: Btw, {{Bug|60907}} for ''sd-encrypt'' is similar in effect to what happened back then with ''encrypt''. Odd. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:53, 12 January 2019 (UTC)<br />
<br />
== Can we rename "Plain dm-crypt" to "LVM on plain dm-crypt" ==<br />
<br />
This is because I want to add "GPT on plain dm-crypt". Note that this proposal is different from the change from before because of the explicit "plain" in the section title. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 01:20, 17 January 2019 (UTC)<br />
<br />
:I see, can you make a very quick draft to understand better what you're proposing? What are advantages and disadvantages compared to the LVM method? If there isn't much difference perhaps it would be better to just add it as a variation Tip in the plain dm-crypt scenario? -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:31, 18 January 2019 (UTC)<br />
<br />
:: The essential differences of using GPT instead of LVM are:<br />
<br />
:: * Advantage: No need for userspace daemons (besides possibly udev, which is running constantly on almost all Archlinux machines anyways, I presume). Speculation: this means faster bootup.<br />
<br />
:: * Disadvantage: There is currently no support for detecting and mapping GPT partitions that reside on device maps, like there is for LVM volumes. Thus the user would need to set up an Udev rule or just a command in a mkinitcpio hook to detect and map the GPT partitions as device mapper maps. Kpartx or partprobe can be used for that. (An alternative to using device mapper would be to use losetup to access the partitions as loopback devices, but I think that would be less performant.)<br />
<br />
:: Another, small, change from the "Plain dm-crypt" section that I want to make in the new section is using only one removable flash drive instead of two. So the flash drive would have two partitions. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 23:54, 18 January 2019 (UTC)<br />
<br />
::: After reading the relevant mailing list thread, I came to the conclusion that the 'encrypted GPT use case' targets situation when '''1)''' plain dm-crypt is desired for deniable encryption reasoning and LUKS header is avoided (note, this could be partially archived by detached LUKS header, personally I like plain dm-crypt, but many will object that deniable encryption of 500+GB space is nonsense) '''2)''' user wants to encrypt several 'partitions' (in abstract sense) at once (without having 3+ separate partitions with different passwords) but does not want to use LVM for some reason (if LVM is avoided because of additional layer costs - this argument is weak, because what is the evidence that these costs are significant? how much does LVM reduce IO read/write? how much does it slow boot? If not costs, then what is the reason which makes LVM an unaccepted alternative?) '''3)''' user wants to use filesystem which does not support 'logical' partitions, like btrfs, OR, if such system cannot have swap space. For example, a user wanting only ext4 partitions, or user wanting both btrfs AND swap partition (for example, he likes compiling Chrome browser). I may be wrong here, but propose that such type of information should be included. --[[User:Mxfm|Mxfm]] ([[User talk:Mxfm|talk]]) 12:47, 19 January 2019 (UTC)<br />
<br />
::::The "partition table on plain dm-crypt or LUKS" scenario would involve modifying/creating mkinitcpio hooks. As such I do not think it could be placed in [[dm-crypt/Encrypting an entire system]]. The only place for such a setup would be the same place where the "[[dm-crypt/Specialties#Encrypted system using a detached LUKS header|Encrypted system using a detached LUKS header]]" scenario is - [[dm-crypt/Specialties]] (aka ''dm-crypt/Weird and unusual setups''). -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 12:58, 19 January 2019 (UTC)<br />
<br />
::::: Why would mkinitcpio hooks cut be the cut off point for what makes it in [[dm-crypt/Encrypting an entire system]]? That makes no sense. This proposed section would logically appear right beside the current "Plain dm-crypt" section, because it also uses "Plain dm-crypt", unlike the rest of the page which uses LUKS. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 13:15, 19 January 2019 (UTC)<br />
<br />
::::::None of the other scenarios in [[dm-crypt/Encrypting an entire system]] require creating custom hooks. I don't think we should add such complex setups to this page. Regardless of that, I support renaming the "Plain dm-crypt" scenario to "LVM on plain dm-crypt" -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:44, 19 January 2019 (UTC)<br />
<br />
::::::: Is creating a hook and adding it to mkinitcpio.conf really such a hassle? The page already suggests using some configuration files, like fstab and crypttab; so I do not see the rise in complexity from using hooks. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 13:50, 19 January 2019 (UTC)<br />
<br />
::::::::It might be, but I guess that depends on how complex it is. If the hook or udev rule could be packaged (even in AUR), then that would be even better. To clarify, I'm not trying to dissuade you, but without a ready draft it's hard for me to evaluate the scenario. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:01, 19 January 2019 (UTC)<br />
<br />
::::::::: Just a single command is really necessary: either '''kpartx -a disk''' or '''partprobe disk'''. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 14:11, 19 January 2019 (UTC)<br />
<br />
:::::::::: If you look over the different scenarios on this scenario page, you won't find custom hooks/udev rules/etc. for now, because (1) they are meant as installation examples with the tools on the ISO, i.e. to keep focus. (2) Maintainability of non-standard tools/hooks is a general issue. <br />
:::::::::: @Neven: reduction to one flash drive is mentioned in the first tip already. I'm against explicitly using a single flash, because it contravenes reasons to use plain dm-crypt in the first place. Remember boot loader configuration in the example gives away the location of a key-file, hence, if you have it on one flash ..<br />
:::::::::: I'm +1 to nl6720's suggestion to add the custom hooks to a new subsection in [[dm-crypt/Specialties]]; there is more room to explain pros&cons of your new kpartx method. ('''mod note''' seems useful to continue this branch at the end of the next branch) --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 14:42, 19 January 2019 (UTC)<br />
<br />
:::::::::::I see this is an interesting exercise, but without a clear technical definition of its benefits (which should have greater extent than other variations such as detached headers), its use cases would practically overlap those for the traditional LVM method, also in lack of scientific benchmarks that prove a noticeable performance improvement, so +1 to add this to the Specialties page and link to it from a Tip as a variation to the plain dm-crypt scenario.<br />
:::::::::::Even if this method was considered distinct enough to be given a separate scenario (which I repeat I'm against at the moment), I think the hook should still be put in /Specialties and linked from the scenario.<br />
:::::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:40, 20 January 2019 (UTC)<br />
<br />
Maybe it would be even better to replace "dm-crypt" with "encryption" in the title, or maybe something like "LVM/GPT behind a ciphertext" would be even better. That is because dm-crypt is not a format, but rather just a method in the kernel of doing encryption without any header or metadata. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 10:18, 17 January 2019 (UTC)<br />
<br />
:"Plain dm-crypt" is an expression that is used all over {{man|8|cryptsetup}}, maybe you're kind of right in ideal terms, but often technical jargon relies on conventional idioms that, despite not being literally correct, do a better job at conveying the intended meanings because of their widespread traditional usage, compared to perhaps more accurate but less recognized/able phrasings. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 16:31, 18 January 2019 (UTC)<br />
<br />
: Now that I think about it, I only thought of this because I forgot that this page was about dm-crypt instead of about disk encryption in general. So, the parent paragraph can just be ignored. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 23:57, 18 January 2019 (UTC)<br />
<br />
: Can you explain your proposal better? What exactly you want to change? Without clarifications, your proposal is controversial, because you essentially propose rename 'plain dm-crypt' to 'LVM on plain dm-crypt' which is obviously false. These are two different use cases and hiding one of them behind the other is incorrect. For example, I use plain dm-crypt, but do not use LVM. If you propose to rename entire page, than it seems uresonable, because in current [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_entire_system&type=revision&diff=563591&oldid=563545 form] the page does not contain information ''only'' about LVM, it has sections regarding encrypted boot and swap. If you propose to rename specific section 'Plain dm-crypt', then it is also incorrect because that section has nothing to do with LVM. It looks like you have implicit assumption (from your experience) that there are only two use cases - LVM on plain dm-crypt and GPT on plain dm-crypt (and there is no plain dm-crypt without LVM/GPT use case). Contrary to this view, in my opinion the situation is completely different. The majority use cases are LUKS (possibly with LVM) and plain dm-crypt (possibly with LVM). The encrypted GPT use case is a new one which was covered in recent [https://lists.archlinux.org/pipermail/arch-general/2019-January/045968.html mailing list thread] and could be supported in future. --[[User:Mxfm|Mxfm]] ([[User talk:Mxfm|talk]]) 12:25, 19 January 2019 (UTC)<br />
<br />
:: You are being kind of confusing here with your expression, so it seems to me that you are saying a lot of irrelevant or obviously false stuff, but I will try to respond anyway:<br />
::* I am proposing to rename the "Plain dm-crypt" section, not the entire page.<br />
::* The section in question is about LVM on plain dm-crypt, thus the proposed name. I can not fathom why would you say it is not about LVM.<br />
::* I did not understand the stuff at the end at all. [[User:Neven|Neven]] ([[User talk:Neven|talk]]) 13:11, 19 January 2019 (UTC)<br />
<br />
::: I think Mxfm simply overread that you already dismissed the rename idea, and at the end Mxfm gave a first-hand example of why we can't feature full-length example scenarios for all possibilities. <br />
::: Still, to me it is out of question that we should find a place where your approach can be explained adequately & currently I think the above suggestion to add to [[dm-crypt/Specialties]] and crosslinking it is best. Once that part is in place and linked to the existing plain dm-crypt example in this page, it is easier to decide if it makes sense to add a totally new scenario for it, or crosslinking from/to the plain dm-crypt scenario suffices. Thoughts? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 14:42, 19 January 2019 (UTC)<br />
<br />
== Encrypted boot partition (GRUB) section needs revision ==<br />
<br />
A few weeks ago, I used the guide here for setting up LVM on LUKS with an encrypted boot partition. There are two parts of this section that I think need revision. First, under '''Configuring GRUB''', running ''grub-install'' should been done after editing ''/etc/default/grub'', otherwise errors come up involving the ''GRUB_ENABLE_CRYPTODISK'' line. Second, running ''grub-mkconfig'' in the last step will actually hang for a while and fail. The supposed reason (being updates with LVM2) and a workaround is proposed in [https://bbs.archlinux.org/viewtopic.php?id=242594 this Arch Linux forum post] from a month ago. [[User:Starclimber|Starclimber]] ([[User talk:Starclimber|talk]]) 00:55, 23 January 2019 (UTC)</div>Starclimberhttps://wiki.archlinux.org/index.php?title=ArchWiki_talk:Sandbox&diff=564351ArchWiki talk:Sandbox2019-01-23T00:34:59Z<p>Starclimber: /* greetings */ new section</p>
<hr />
<div>==Comments==<br />
<br />
Hello, how are you? -- [[User:Acgtyrant|Acgtyrant]] ([[User talk:Acgtyrant|talk]]) 15:17, 27 August 2013 (UTC)<br />
:Fine, thanks, and you? -- [[User:Acgtyrant|Acgtyrant]] ([[User talk:Acgtyrant|talk]]) 15:17, 27 August 2013 (UTC)<br />
::Tres bien) -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 05:33, 28 January 2014 (UTC)<br />
:: how do you edit the wiki?<br />
Testing [[User:Tech2077|Tech2077]] ([[User talk:Tech2077|talk]]) 21:38, 3 July 2015 (UTC)<br />
:::: Uh, tu parles francais [[User:Kycok|Kycok]]? I am from switzerland but I hated french in school and now I am learning it every single day. --[[User:Ndalliard|ndalliard]] ([[User talk:Ndalliard|talk]]) 04:42, 31 July 2015 (UTC)<br />
Trying to contribute here. ([[User:Amoros|Amoros]]) ([[User talk:Amoros|talk]]) 15:37, 12 August 2015 (UTC)<br />
<br />
Hi I'm new here [[User:Chrisfryer78|Chrisfryer78]] ([[User talk:Chrisfryer78|talk]]) 08:36, 7 November 2015 (UTC)<br />
:Hello, I'm new here too! This is a test. [[User:Nullifer|Nullifer]] ([[User talk:Nullifer|talk]]) 07:48, 30 December 2016 (UTC)<br />
:Hello this is a test reply :) [[User:Viktorstrate|Viktorstrate]] ([[User talk:Viktorstrate|talk]])viktorstrate 16:10, 4 July 2018 (UTC)<br />
<br />
== A new section should be added ==<br />
<br />
I'd like to propose to change blahdieblah!<br />
<br />
[[User:E-type|E-type]] ([[User talk:E-type|talk]]) 17:38, 9 October 2016 (UTC)<br />
<br />
<br />
adding my contributions to the new section, test edit blah blah ...<br />
<br />
[[User:Fawix|Fawix]] ([[User talk:Fawix|talk]]) 20:14, 1 January 2017 (UTC)<br />
<br />
Testing stuff in the sandbox [[User:RobU3|RobU3]] ([[User talk:RobU3|talk]]) 05:15, 30 January 2018 (UTC)<br />
<br />
== New test section ==<br />
<br />
Hello Sandbox! <br />
<br />
-- [[User:Raczek|Raczek]] ([[User talk:Raczek|talk]]) 13:43, 11 May 2017 (UTC)<br />
<br />
Just a test...<br />
[[User:Leventel|Leventel]] ([[User talk:Leventel|talk]]) 10:07, 12 May 2017 (UTC)<br />
<br />
Looks like I'm the newest user now. [[User:Mycatfishsteve|Mycatfishsteve]] ([[User talk:Mycatfishsteve|talk]]) 21:56, 6 June 2017 (UTC)<br />
: Short joy ! I myself wonder how to add {{ic|codelines}} [[User:Lafleur|la Fleur]] ([[User talk:Lafleur|talk]]) 23:55, 12 October 2018 (UTC)<br />
<br />
== Add topic test ==<br />
<br />
test<br />
-- [[User:Z32O|Z32O]] ([[User talk:Z32O|talk]]) 17:14, 13 Oct 2017 (UTC)<br />
:I think it's nice test ;)<br />
:[[User:Elnee|Elnee]] ([[User talk:Elnee|talk]]) 09:02, 28 November 2018 (UTC)<br />
<br />
== New topic to talk about ==<br />
<br />
Bla bla bla bla bla.<br />
[[User:Mouseman|Mouseman]] ([[User talk:Mouseman|talk]]) 13:07, 21 October 2018 (UTC)<br />
<br />
== Test ==<br />
<br />
Talk test<br />
--[[User:Alpery|Alpery]] ([[User talk:Alpery|talk]]) 15:27, 5 January 2019 (UTC)<br />
<br />
== greetings ==<br />
<br />
hi i'm a new arch wiki person [[User:Starclimber|Starclimber]] ([[User talk:Starclimber|talk]]) 00:34, 23 January 2019 (UTC)</div>Starclimber