User talk:nl6720

From ArchWiki
Jump to navigation Jump to search

Linking a category

Regarding [1], you can use a colon to link categories:

Merge-arrows-2.pngThis article or section is a candidate for merging with Category:Boot loaders.Merge-arrows-2.png

Notes: foo bar (Discuss in User talk:Nl6720)

See: mw:Help:Categories#Linking_to_a_category -- Alad (talk) 12:50, 25 August 2016 (UTC)

Thanks! -- nl6720talk 12:57, 25 August 2016 (UTC)

Email address

Hey Nl6720,

You've disabled email from other users, but I'd like to send you a private message. If interested, would you mind contacting me on alad <at> archlinux <dot> info (address in ArchWiki:Administrators)?

Cheers -- Alad (talk) 11:50, 2 October 2016 (UTC)

I re-enabled email from other users. -- nl6720talk 13:54, 2 October 2016 (UTC)

Clarification for: The content seems questionable too, but I know nothing about these frameworks

It's a problem I met, for which I couldn't find a solution with googling, so I had to retreat to asking at IRC. In short, it's that the default Archlinux config shipped somewhere in /etc/ overwrites variables for runtime, i.e. one can't even overwrite them manually. I thought it would be useful to many others. Probably, it may cause problems not only with "oh-my-zsh", but I decided to put info in that paragraph because I'm not sure if there is a better place.

And sorry for html formatting, markup is pretty unusual, and the formatting page is surprisingly unhelpful. I.e. how to write a link I figured out only because I thought, perhaps using the same markup formatting; which turned out to be right. Hi-Angel (talk) 10:23, 6 October 2016 (UTC)

User's files are sourced after their system-wide counterparts (i.e. ~/.zshrc is sourced after /etc/zsh/zshrc), so things set in ~/.zshrc should normally not be undone by /etc/zsh/zshrc. But I guess it's possible for /etc/zsh/zshrc to define a function that changes $PROMPT under certain conditions. I probably shouldn't have called the content questionable.
About formatting, start with Help:Editing then Help:Style, Help:Style/Formatting and punctuation and Help:Style/White space. There is also Help:Cheatsheet. -- nl6720talk 10:48, 6 October 2016 (UTC)

GRUB UEFI install

We were amending the page at the same time, can you review my latest change to see if it is consistent with your definition of esp? -- Kewl (talk) 13:04, 5 March 2018 (UTC)

Looks good to me. -- nl6720 (talk) 14:35, 5 March 2018 (UTC)


nl6720 rEFInd is able to:

  • auto-detect the kernels if the file system drivers are there
  • launch the last one booted - for this to work it needs to list all unfolded

so the following minimal configuration works:

# cp /usr/share/refind/refind_x64.efi /esp/EFI/Boot/bootx64.efi
# cp -r /usr/share/refind/drivers_x64/ /esp/EFI/Boot/
# echo 'extra_kernel_version_strings linux,linux-lts,linux-git;' > /esp/EFI/Boot/refind.conf
# echo 'fold_linux_kernels false' >> /esp/EFI/Boot/refind.conf

rod smith was so kind to add the "extra_kernel_version_strings" option end of 2017 so rEFInd could handle the kernel naming conventions in arch. and with it, rEFInds problem of finding the correct fallback image was fixed, and the necessity to provide a configuration. there is no editing of a file necessary, no additional boot parameters, no tinkering with nvram, etc. currently i find really hard to detect out of the description that this works. i am inclined to break up the text slightly different - not focussing on "manual" and "scripted", and "configuration" but more in "install into EFI default location", "install in rEFInd location", "secure boot". currently the section "scripted" contains secure boot, shim, editing files. what you think? --Soloturn (talk) 03:40, 14 March 2018 (UTC)

The first sentence of the section mentions the refind-install script so it should be obvious that the whole section is about using the script. Just in case I've now renamed the section to avoid any confusion. Secure boot is under the "Scripted installation" section because refind-install provides a way to automate installation on Secure Boot enabled systems. I'll repeat, the whole section is about refind-install and its provided options.
extra_kernel_version_strings was added to support multiple kernels without version numbers in their filenames, unless I've missed something rEFInd still doesn't support automatically detecting and matching fallback initramfs images with their respective kernels.
I've removed your "minimal configuration" because it mixed installation (i.e. getting rEFInd binary to the ESP) and configuration (editing refind.conf), those sections are split for a good reason. Before drastically changing an article, you must first discuss it in the article talk page (Talk:REFInd in this case), please read ArchWiki:Contributing#Announce article rewrites in a talk page. Also I would not accept adding echo 'extra_kernel_version_strings linux,linux-lts,linux-git;' > /esp/EFI/Boot/refind.conf to rEFInd, the /usr/share/refind/refind.conf-sample file has a lot of comments explaining its content, it's more useful to copy the sample and edit it. -- nl6720 (talk) 07:20, 14 March 2018 (UTC)

ok, will try. i had enough difficulties with boot loader installation. so much that i took the time to address it with the software itself, and the wiki page. i even asked rod if he would be able to adjust refind a little to make it configuration-less. but he thought using the 2 lines are appropriately minimal - and no editing of a config file would be necessary. while coding arch kernel names into rEFInd would be a bad idea. --Soloturn (talk) 06:18, 19 March 2018 (UTC)

Closing. Any further discussion will be in Talk:REFInd#add a paragraph with simple installation. -- nl6720 (talk) 08:47, 19 March 2018 (UTC)

Firewall Limiting

Hi Nl6720,

Thank you for the improvements to my solution to the firewall. Could I just ask, why is it you chose to explicitly list most the packet types opposed to allowing them all? Is there a security concern when the ones you omitted?

Sainty (talk) 17:42, 1 July 2018 (UTC)

I compared Wikipedia:Internet Control Message Protocol#Control messages and Wikipedia:Internet Control Message Protocol for IPv6#Types with the ICMP types with names in nftables proto.c. I skipped those listed as deprecated and the one I didn't think should be needed. AFAIK only the redirects can potentially have security issues, so I skipped those too. I doubt it's really that much safer to specify only those ICMP types so it could just be considered a personal preference to allow only those that could be needed. -- nl6720 (talk) 15:19, 2 July 2018 (UTC)

Closing of several discussions in one edit

Please use one edit per discussion removal. See [2] -- Alad (talk) 11:47, 20 September 2018 (UTC)

Sorry! Somehow I overlooked that rule in Help:Discussion#Closing a discussion. -- nl6720 (talk) 11:55, 20 September 2018 (UTC)

dm-crypt hooks

>that is obvious since the examples provide full HOOK lines and "udev" is not listed in the example with the "systemd" hook

It is not obvious. The obvious ones are the ones that are highlighted.

How about highlighting udev too so it becomes obvious? —This unsigned comment is by C0rn3j (talk) 09:55, 27 December 2018‎ (UTC). Please sign your posts with ~~~~!

I think it would actually be better to remove bold from systemd, it's not a hook that needs to be added when using full system encryption. Also, you added the note to only one "Configuring mkinitcpio" section, while all of them have the same issue. -- nl6720 (talk) 10:15, 27 December 2018 (UTC)
The style of the HOOK examples now match (Special:Diff/560861, Special:Diff/560863). Closing. -- nl6720 (talk) 08:04, 30 December 2018 (UTC)

firefox edit

special:diff/572054 you could save yourself some writing and link to Desktop_entries#Modify_environment_variables instead -- Ubone (talk) 17:04, 27 April 2019 (UTC)

I didn't notice that section. Thanks! -- nl6720 (talk) 04:07, 28 April 2019 (UTC)

Regarding "Undo revision 574893" and "Undo revision 574894"

I mistakenly had "fixed" the link syntax on the "Persistent block device naming page". Thanks for mentioning the specific style page rule that was in violation (Help:Style#Hypertext_metaphor), that was quite helpful. If you could do that in the future as well for any mistakes I make, I'd greatly appreciate it. In the meantime I'm going to make sure I extensively read over the Help:Style page before attempting to correct style usage, but given how extensive the styling rules are, there's a decent chance I'll make a few mistakes along the way. Linking to the specific rule definitely provides me with good constructive feedback. --Aeros167 (talk) 07:46, 9 June 2019 (UTC)

I usually link the rule of the style issue I'm fixing, unless I'm feeling lazy, but I can't just write "style" in the summary when undoing an edit. And having a proper edit summary is also a wiki rule: ArchWiki:Contributing#Always properly use the edit summary.
You don't need to memorize all the rules, just know where to find them. The related articles box in Help:Style links to most of the relevant pages.
-- nl6720 (talk) 08:12, 9 June 2019 (UTC)

Improving style on external github links

This might be a question better directed at the bureaucrats or site admins, but I'm curious as to your opinion on this as one of the most active maintainers of the site, and you seem to be particularly involved when it comes to link styling. According to Help:Editing#Links, "It is often more useful to give the link an alternative label rather than displaying the URL." (regarding external site links). However, I noticed that on any section that lists a number of applications, such as List of applications, virtually every single one of the external links uses the URL instead of an alternative label.

For sites that are specific to an individual application, I think it is appropriate to show the full url. However, for common sites that are used as a homepage for a number of applications, such as github repositories, it might be a better styling practice to set an alternative label like "github" or "github repository". Help:Editing#Links is not particularly strict on external links, but I personally think it would look significantly cleaner this way. Let me know what you think, I'd like to potentially bring this up with others as well. Also let me know if there's someone specific (such as a bureaucrat or admin that specializes in styling) I should discuss this with.

If the others are on board with this suggestion, I'd be more than willing to start applying this to a number of different pages. I think it would make for a good starter project for me to work on. As a long term aspiration of sorts, I am interested in prospect of eventually becoming a maintainer (I know that I have a long ways to go). I think it'd be a great way to improve my skills at technical documentation, while contributing to one of the most useful sites for linux documentation. -- Aeros167 (talk) 21:32, 9 June 2019 (UTC)

The List of applications page uses Template:App, so you can propose changes in Template talk:App or Help talk:Style. Personally I don't agree to this change, I don't see a need to hide the URL by using a link title in Template:App. If the link was in a block of text, then I could agree to it, but not when specifically listing the URL. -- nl6720 (talk) 07:20, 10 June 2019 (UTC)
Ah no problem, it was just an idea. If the current template is already well established with a fairly recent dedicated page, it will likely stay the same. I'll keep that in mind though for replacing the URL with the substitute if it's in a block of text, I find the text substitutions to be quite useful within those contexts especially. Are there any other frequently used Template pages that would be useful to be aware of? I checked Template (similar to how Help directs to all pages in the help category) but that seems to be a dead end. -- Aeros167 (talk) 09:40, 10 June 2019 (UTC)
AFAIK templates are not categorized so you can find a list of them in Special:UncategorizedTemplates. A more useful list, separating them by usage, is available in Help:Template#List of templates. -- nl6720 (talk) 10:13, 10 June 2019 (UTC)

Is there any reason why you chose to remove the note about ISO Image mode?

The note that says DD Image mode has to be used is not correct. ISO image mode will work for most people. You only need to use DD Image mode if the drive doesn't boot. Tonij (talk) 17:12, 2 August 2019 (UTC)

DD Image mode writes the iso to the drive as it was intended by Arch developers while using ISO image mode means trusting that Rufus correctly copies the bootloader configuration. Any messing with the boot setup is bound to result in some incompatibilities, which is exactly what happens with the crap known as UNetbootin, luckily Rufus has not deteriorated to such extent. I restored Special:Diff/578638 in Special:Diff/578856. Frankly, I'm not a fan of Rufus since it keeps hiding useful features. [3][4] -- nl6720 (talk) 18:51, 2 August 2019 (UTC)

Also if someone is using GPT, they never had any intention of booting in BIOS. What is the point of saying that they should use MBR in that situation? Tonij (talk) 17:22, 2 August 2019 (UTC)

That's an unfounded claim. The installation media should be bootable for both BIOS and UEFI systems and that means using MBR in Rufus. Any other specialization is outside the scope of the USB flash installation media article. -- nl6720 (talk) 18:51, 2 August 2019 (UTC)

Read this: Tonij (talk) 17:32, 2 August 2019 (UTC)

dm-crypt/Encrypting an entire system

About the revert: Ok, thanks. I also had problems with some kind of "escape template-breaking characters" that I couldn't solve before you reverted very fast (so I was looking into changing something wrong with the link, but you very too fast). In the future, there will be a release where LUKS2 can be used... Then the wiki could be updated, I guess. I wasn't sure about how often people updated the wiki (and am not used to this, one time has to be the first), but it seems very frequently you guys update the wiki and thanks a lot for that. I also didn't remove the LUKS1-warning, because some people will use old versions for a long time. Thanks and I'll leave it here until we have a release and people begin using that new release with LUKS2-support (but then you or someone else probably updates the wiki before). Cheers! :-) Newsboost (talk) 17:51, 26 January 2020 (UTC)

The template-breaking character issue was because of = in the Phoronix URL. Since the URL was in Template:Warning, normally you would need to escape it with e.g. {{Warning|1=text text []}}, but since it starts with a list, it becomes a little more annoying:
* list item
* list item []
Without <nowiki></nowiki> the first item would not get parsed as a list item.
About GRUB, when a new release with LUKS2 support lands in the stable repos, feel free to update the warnings (or remove them if GRUB miraculously gains Argon2 support), until then I think that the dm-crypt pages should retain the current warnings. I'm certain I'm not the only one with such opinion.
That said, this does not prevent you from editing GRUB#Encrypted /boot. Currently it does not give a clear solution for using LUKS2, but only hints about PBKDFs. It should be possible to use GRUB from git with LUKS2 created with the cryptsetup luksFormat --pbkdf pbkdf2, but I couldn't test it since grub-gitAUR didn't build for me when I tried it a few weeks ago.
Anyway, don't get discouraged from editing the wiki just because one of your edits was undone :)
-- nl6720 (talk) 07:11, 27 January 2020 (UTC)
Yeah, frontend web-devel isn't really my thing, this template-breaking character stuff confused me a lot. So thanks a lot for explaining some details about this, I had major challenges "fixing" that broken template-stuff. About GRUB and LUKS2: I think I'll also skip the grub-git-method (I don't want to risk anything, but after a new release has been out for some weeks it'll be safer to test). I've been so unlucky for the past year that I for various reasons had to reinstall Arch Linux and therefore have been through the encrypted boot-procedure (too) many times recently. I takes me around 30 hours to fully setup an Arch Linux to my taste, incl. getting packages setup, window managers etc up and running so I hope I won't have to do it too many times again in year 2020 (this time I'll take an image with clonezilla and hopefully that can be used to save time in the future). I use luks1 for boot partition /boot, which after unlocking, unlocks my root-partition which is actually contained in a luks2-container with detached header and LVM inside. So I guess I'm not a normal user, anyway, maybe other people could use that procedure I've gathered and am using with the detached header... I'll watch out and hopefully soon I can use luks2 (and maybe detached header, e.g. on USB-stick) for the boot-partition. Once GRUB with LUKS2-support is stable, I'll see if I can contribute a bit about the detached header-setup, which I think is really nice. There are some details I'm not fully into, e.g. Argon2 and pbkdf2 but I'll see if I can contribute somewhere in the future, when something strikes my eyes. So I fully understand you, I think, this just serves as a bit of practice for me so I better know how things work the next time. Thanks a lot for your feedback, I'll have that in mind when I in the future browse and use the wiki! Newsboost (talk) 20:32, 27 January 2020 (UTC)
Just in case you don't know, the setup for LUKS with a detached header is documented in dm-crypt/Specialties#Encrypted system using a detached LUKS header. -- nl6720 (talk) 10:26, 28 January 2020 (UTC)
I'm not sure if I've seen that (can't remember). I usually have a folder with text-files that contain instructions for how to setup things and once I've done things a few times, that becomes my only source of "truth" or information (unless a new version of something causes unforeseen problems, in which case I try to solve it and update the instructions again till next time). That being said, I think the arch linux wiki is a great source and many of my own rewritten instructions are based on info from the wiki in some form (sometimes I extend things with detailed examples, I think the wiki isn't suited for that). I'll have in mind that if I notice something on the wiki that other users could benefit from, I'll see if I can contribute. I also copied your comment about the template-stuff to my own (+ a reference to the broken url), so I guess I can always easily find that info again, if something similar appears, i.e. I would then be less dependent on remembering where to find the this conversation)... Now I went through the process of editing here a few times, I think I'll feel more comfortable the next time, thanks :-) Newsboost (talk) 17:01, 28 January 2020 (UTC)

F2FS warning

Hello, I see you reverted my F2FS warning. Fair point for the doc. I have this link [5] which gives a lot of details on what is going on. Basically, if you shut down your system improperly at the wrong time, F2FS will be corrupt beyond repair. Even fsck.f2fs will error out. I had found a weird, temporary fix allowing to mount the filesystem read only and even to allow the system to boot for a day or so. I've got a write-up (in French) about that on my blog ([6]) This has happened to several users before, and most smartphone manufacturers, Samsung itself included (they created F2FS), don't use it on their phones because of the stability issues. Do you think this data is sufficient? Aviallon (talk) 12:34, 25 September 2020 (UTC)

I didn't doubt that the issue with F2FS is real. I've had my own issues with this file system (FS#63839) which made me switch to a different one. It's just that without any sort of reference that warning was fairly useless. Your links look good and there's even a kernel bugzilla link in you blog. If you can create a section in F2FS based on you blog post (adjusted for the wiki's style, of course) then it would be perfect :) -- nl6720 (talk) 13:23, 25 September 2020 (UTC)
Understood! I will do that right away! Does that mean I should only put this information in Known Issues, and that I shouldn't put a warning like with Btrfs ? Aviallon (talk) 13:56, 25 September 2020 (UTC)
You should definitely document your issue in "Known issues". Now whether it should be also linked from a warning in the intro, I'd say go by the consensus of Talk:F2FS#Adding warning about F2FS potentially being unsafe? -- nl6720 (talk) 14:05, 25 September 2020 (UTC)

TPM/Data-at-rest encryption with LUKS

Hello, I'm curious about a recent edit you made to TPM#Data-at-rest_encryption_with_LUKS. I am the one who wrote the part that you edited, but I'm fine with most of your changes. The only thing I take issue with is the statement "This means that access to data is not protected in case the hardware gets stolen." This seems to imply that if the hardware is stolen, the data is as good as unencrypted. Given that full disk encryption is mostly useful in the case that the hardware is stolen, this implies that using a TPM to unlock your drive is as good as not encrypting it at all, which I don't think is fair to say.

Cold boot attacks, bus sniffing attacks, and other potential ways of circumventing a TPM are not trivial to perform, and are no comparison at all to the ease with which one can access an unencrypted drive. Furthermore, in the (admittedly unlikely) case where an attacker steals only the drive and not the entire computer, the fact that a TPM was set up to unlock the drive won't help them at all. Perhaps this could be changed to something like "This increases the number of options an attacker has to attempt to steal the data," or even "This makes the data significantly less secure."


Forgonewarrior (talk) 08:37, 10 April 2021 (UTC)

By "hardware" I meant the whole PC not just the drive. If TPM automatically unlocks the the LUKS encrypted root volume on boot, then the thief just needs to power on the PC to get access to the data. So yes, it is almost as good as unencrypted. Getting passed user login is out of scope, and, while I can't think of a way to sidestep it, relying on it for data safety would be naive. See also -- nl6720 (talk) 08:46, 10 April 2021 (UTC)

Konsole true color

I have seen your edit in Konsole. You changed TERM=konsole-256color to TERM=konsole-direct. I was the one who added that section.

It seems TERM=konsole-direct is broken. vim and nvim don't display correctly and vis simply segfaults.

But you were right TERM=konsole-256color is not for true color.

I think we should undo your last edit and change the section title from "True-color programs do not display correctly" to "Some color programs do not display correctly".

—This unsigned comment is by ENV25 (talk) 09:30, 17 April 2021 (UTC). Please sign your posts with ~~~~!

From what I see, nvim with set termguicolors[7] looks the same with TERM=xterm-256color, TERM=konsole-256color and TERM=konsole-direct. -- nl6720 (talk) 13:25, 17 April 2021 (UTC)