From ArchWiki
(Redirected from Talk:Mkinitcpio-btrfs)
Jump to: navigation, search

Talking about other hooks and a more generic view of the early userspace

I am the current maintainer of the the dropbear_initrd_encryptAUR, and, I've also developed some other mkinitcpio hooks, such as: mkinitcpio-pppAUR and mkinitcpio-ddnsAUR. I will write some wiki pages describing them, but I would also like to talk more about the early userspace. So, my question is, should I make an early userspace page, should I write a page just for the hooks? Should I write it and make it related to the mkinitcpio page? Thanks in advance.

Grazzolini (talk) 01:03, 11 February 2015 (UTC)

It depends a lot on how much content you're actually going to write. I suggest starting by expanding on the early userspace in Arch boot process; then, if what you write gets too long, we can always consider splitting the page. About custom/additional hooks you might create a section below Mkinitcpio#Common hooks, following the same principle: if the content gets too long/detailed to stay in the page, we can split it later. In any case, it's very important that you try your best to avoid duplicating existing information in other articles, and instead either add links to them, or move that information to your new content, if it fits best there, and add links to the new location from the articles where the info was removed. — Kynikos (talk) 4:32, 12 February 2015 (UTC)
Thank you for your information Kynikos. I'll be contributing these changes very soon. Grazzolini (talk) 12:54, 12 February 2015 (UTC)

Mark /usr with a passno of 2, not 0

mkinitcpio#/usr as a separate partition firmly suggests to mark /usr with a passno of 0 in /etc/fstab. The way I understand man fstab, 2 is the correct number for the task. Am I wrong? Regid (talk) 19:09, 6 April 2017 (UTC)

It also suggests adding the fsck hook to your config. Seeing as the regular fsck binaries reside on the /usr partition, this is needed to actually make it possible to fsck it at startup. The entry in /etc/fstab should thus be 0. Koneu (talk) 07:27, 7 April 2017 (UTC)
I see your point about the binaries residing on /usr. Still, with a passno of 0 you set no automatic fsck at all, don't you? Would you set passno for / to 0 when usr is an integral part of /?
Indeed the fsck hook copies fsck binaries to the initramfs, and possibly ignores passno for / and /usr at runtime. As an aside, its help text should mention usr, not just /.
Regid (talk) 10:12, 7 April 2017 (UTC)

Talking about LUKS/LVM with sd-encrypt example

Formerly there was a link to the forum that was ambiguous about where the UUID were generated from. enckse documented clearly the same use case within this page, which was reverted by Lahwaacz in this change. The current edit of the page removes a reference to the forum post entirely. Where should the writeup from enckse be placed? - storrgie 22:05, 23 October 2017 (UTC)

In the previous form, ie., as a tutorial, it would belong in someone's namespace. If you just want to capture the bit about determining UUIDs, then that is already documented on the relevant page. Jasonwryan (talk) 22:19, 23 October 2017 (UTC)
If you review the forum post mentioned it isn't that I'm saying users don't know how to capture UUID. I'm saying that in the case of LUKS/LVM the rd.luks.uuid requires the block device UUID and the root=UUID= requires the UUID of the root volume group. This is what is ambiguous in the original forum post. Let's be clear, this is a commonly followed install pathway (LUKS/LVM), so why let users be confused when we've got a documented use case? - storrgie 22:25, 23 October 2017 (UTC)
Then that relevant factoid belongs on the dm-crypt page page. Jasonwryan (talk) 22:39, 23 October 2017 (UTC)
I've tried to place it in an appropriate place on that page, please advise. - storrgie 22:50, 23 October 2017 (UTC)
I said *not* the entire tutorial, just the relevant snippet about locating the correct uuids. Jasonwryan (talk) 23:20, 23 October 2017 (UTC)
It'd be nice to have a proposed modification rather than just slapping the revert button. - storrgie 23:41, 23 October 2017 (UTC)
enckse's writeup is really no better than the forum post, it just describes how to do one specific thing without explaining the steps. That's not the wiki way, the wiki should explain the steps in some organized way and let users combine them as they want.
That said, I think that everything discussed here is already on the dm-crypt/System configuration page:
Though I must admit, that I can't find the kernel parameter anywhere on the wiki. I have no idea what it's for and the forum post does not explain it either. Is it necessary for resume? Or for LVM? Or the LUKS/LVM combo? If you find out, feel free to explain it here so we can find an appropriate place on the wiki for it.
-- Lahwaacz (talk) 07:25, 24 October 2017 (UTC) seems to be a dracut specific thing. -- nl6720 (talk) 13:26, 29 October 2017 (UTC)
[1] confuses me. Is /etc/crypttab meant to be /etc/crypttab on real root or /etc/crypttab in initramfs (i.e. /etc/crypttab.initramfs on real root)? -- nl6720 (talk) 13:39, 29 October 2017 (UTC)
Since the snippet is from the systemd-cryptsetup-generator(8) man page, I'd say it's the root where systemd-cryptsetup-generator is run. -- Lahwaacz (talk) 13:56, 29 October 2017 (UTC)
mkinitcpio#Non-root drives are not decrypted by sd-lvm2 hook doesn't make the distinction, which makes the whole section nonsense. Why would you expect sd-lvm2 to have access to block devices that are decrypted after boot (those listed in /etc/crypttab on real root)? Using /etc/crypttab.initramfs is far simpler than messing around with all those rd.luks. and luks. parameters. -- nl6720 (talk) 14:06, 29 October 2017 (UTC)
I have no idea, I just moved the section from systemd-boot. See also Talk:Systemd-boot#Move_section_.22Non-root_drives_are_not_decrypted_by_sd-lvm2_mkinitcpio_hook.22. -- Lahwaacz (talk) 14:31, 29 October 2017 (UTC)