User talk:nl6720

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

https://wiki.archlinux.org/index.php/USB_flash_installation_media#Using_Rufus

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. [1][2] -- 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: https://www.reddit.com/r/ManjaroLinux/comments/b5fzj4/make_sure_you_burned_the_iso_in_dd_mode/ejdcz9y?utm_source=share&utm_medium=web2x Tonij (talk) 17:32, 2 August 2019 (UTC)

Removal of a note on placing swap after boot/ESP

Hello. I noticed you reverted two of my edits:

• https://wiki.archlinux.org/index.php?title=EFI_system_partition&diff=next&oldid=800115
• https://wiki.archlinux.org/index.php?title=Partitioning&diff=next&oldid=800144

Layouts offered in Partitioning#Example_layouts are, as far as I understand, examples. Not suggestions or requirements. It’s up to the administrator to decide the layout, isn’t it? And Arch Wiki is in this case offering help in making the decision. So the hint about the order, not expressed anywhere else in these articles, is IMO reasonable. It’s also not out of the blue: it’s triggered by the recent issues with the boot/ESP being too small.

Of course we may accept your line of reasoning, but in this spirit entire sections of this article should be deleted, because they discuss things either already in the examples or opposing examples.

Also: contrary to the revert reason for /boot, examples don’t even discuss a separate boot partition for MBR setup.

I ask for reconsidering the reverts. Both of them. The hint in ESP article was added, because dealing with ESP is a separate topic. The administrator is not expected to read the entire article on partitioning, when setting up ESP. --Mpan (talk) 09:00, 11 February 2024 (UTC)

If you're partitioning, you rarely create only the ESP and no other partition. The creation of individual partitions (ESP or the /boot partition) does not concern other partitions on the table. That's why I said it's out of scope.

I don't feel like the hint in EFI system partition#Create the partition helped much. If it would instead say that you can sacrifice an adjacent swap partition to increase the ESP size, then I would see some value in it. But then you're also dealing with FAT resizing for which the wiki doesn't even have instructions. And gparted cannot even resize FAT partitions of certain sizes.

-- nl6720 (talk) 09:16, 11 February 2024 (UTC)

My feeling is that a person reading the ESP article may be making choices about its size. Being aware of how the layout may be a factor is IMO relevant.

But, assuming otherwise, that would only explain the note being inappropiate in the ESP article. Not in the general partitioning article, which discusses both the /boot partition and ESP partition. I still believe that the note should be present at least in the partitioning article.

/boot doesn’t have to be FAT. I any case a filesystem that tiny doesn’t need to be resized either: it can be recreated. Resizing is relevant if size restrictions require the operation to be done in-place.

--Mpan (talk) 03:18, 12 February 2024 (UTC)

I just don't see how these hints could help anyone. There's no way to know how the partition space recommendations/requirements will change in the future. If you suggest sacrificing the adjacent swap partition to enlarge the /boot partition, then you may end up without any swap partition (sure, there are alternatives, but those are not always feasible). -- nl6720 (talk) 12:46, 13 February 2024 (UTC)

There is a way: knowing the past. The requirements will grow, likely at steady, slow rate. If I’m wrong on that, the worst outcome is: nothing happens. If I’m right, in the future users have a way to easily remedy the problem and support people have a ready answer to these asking for help.

The boot partition is much smaller than swap and the latter can be easily extended with devices/files placed anywhere. So there is no risk of running out of swap. Even if that was a risk, it’s still better than being unable to update system, because initramfs images do not fit. --Mpan (talk) 11:45, 15 February 2024 (UTC)

I'd like to chime in to drop a suggestion: How about you (@Mpan) add a EFI system partition#Troubleshooting subsection for the case of initramfs creation/kernel update failing due to space limitations. In that it could explain how to create a new larger ESP and deploy it safely (switch esp), and integrate your tip to reuse an existing swap into it (e.g. in case there is no free space on the main drive). This would be safer, universal and needed anyway, because as nl6720 already said, extending FAT comes with its own caveats. --Indigo (talk) 14:54, 16 February 2024 (UTC)

Indigo, I’ve already answered this above. I also don’t understand, why is this constantly diverging into tangential topics, which I’m expected to address, while the core subject is avoided.--Mpan (talk) 15:49, 17 February 2024 (UTC)

The core issue being the hints about future-proofing the partition layout? Sorry, but I just don't find the hints very useful in the places they were added. There were no instructions to act on the suggestions, so all you got was a vague hint. -- nl6720 (talk) 16:24, 17 February 2024 (UTC)

It’s already covered by the wiki--Mpan (talk) 17:38, 17 February 2024 (UTC)

See, your tip can be generalised "If a separate swap partition is used, placing it in between other partitions may provide some margin if one of the adjacent partitions has to be resized later.", or phrased more specific "If an LVM and a separate swap partition are used, creating swap as an LVM logical volume offers most flexibility to reallocate space.". This just to emphasize again that there is no single best method to suggest (& users following the example layouts verbatim have it your way). Besides, it's contextually wrong to mention swap in the /boot subsection, when there is a separate subsection covering swap in the article anyway.

I still believe that (a) your intention would be better served with a EFI system partition#Troubleshooting item and (b) advising how to recreate a larger /boot and switch over is way safer than attempting a resize of the (unmounted yet) active one. I don't see what's tangential about that thought, and the more it can be crosslinked, the better. Give it another thought. --Indigo (talk) 22:20, 18 February 2024 (UTC)

Self-encrypting drives

https://wiki.archlinux.org/index.php?title=Self-encrypting_drives&diff=824746&oldid=824715

You example

> HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block sedutil filesystems fsck)

contradicts with the first line of the abstract Self-encrypting drives#Custom hook in mkinitcpio config

"add the sedutil hook before udev."

In your example sedutil is after udev. I don't know what is wrong, maybe your HOOKS example is ok and we need to fix this recommendation: "add the sedutil hook before udev.". kullfar (talk) 15:28, 9 January 2025 (UTC)

Sorry, I missed that sentence. I fixed the hook order now. I haven't actually tested sedutil, so I can't say if sedutil really needs to run before the udevadm trigger commands of the udev hook. --nl6720 (talk) 10:19, 10 January 2025 (UTC)

But... now my edit (which you removed) about adding 'nvme' to MODULES may become relevant again ;-)

Because now the 'sedutil' hook is executed before the 'block' hook

At least it helped me. kullfar (talk) 12:15, 10 January 2025 (UTC)

The block hook doesn't get executed, it doesn't have a runtime hook. -- nl6720 (talk) 08:22, 11 January 2025 (UTC)

Hmm, I see, you're right. Okay, then it's some kind of magic for me ;-)

I 'echo'-ed /dev/sd* and /dev/nvme* in sedutil hook. And I got only my sda drive in the output, and no nvme. After I added 'nvme' to MODULES, sedutil hook started echo-ed /dev/nvme* as well. Now I can't figure out why it's like that in my case. Maybe the asynchronous nature of some boot processes. Maybe 'modprobe nvme' in sedutil hook will help, but I'll leave it as is for now ;-)

Thanks for the clarification. In case of problems I know what to try. kullfar (talk) 15:31, 11 January 2025 (UTC)