Difference between revisions of "Talk:Mkinitcpio"

From ArchWiki
Jump to: navigation, search
(page title: rm closed discussion)
(Improvements for the Common hooks table and section about systemd hook: New reply)
 
(82 intermediate revisions by 21 users not shown)
Line 1: Line 1:
 
{{DISPLAYTITLE:Talk:mkinitcpio}}
 
{{DISPLAYTITLE:Talk:mkinitcpio}}
== keymap v. consolefont ==
+
== Talking about other hooks and a more generic view of the early userspace ==
Using the consolefont hook seems to work as advertised in /lib/initcpio/hooks/consolefont and {{ic|mkinitcpio -H  consolefont}} i.e. I get my font in the early stages of the boot process, while using keymap only sets the font a bit later and mangles Polish accented characters if I'm using {{ic|1=DAEMON_LOCALE="yes"}}. I think we need to add consolefont to the HOOKS list and fix keymap hook description. -- [[User:Karol|Karol]] 11:10, 21 January 2012 (EST)
+
I am the current maintainer of the the {{AUR|dropbear_initrd_encrypt}}, and, I've also developed some other mkinitcpio hooks, such as: {{AUR|mkinitcpio-ppp}} and {{AUR|mkinitcpio-ddns}}. 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.
  
== udev hook ==
+
[[User:Grazzolini|Grazzolini]] ([[User talk:Grazzolini|talk]]) 01:03, 11 February 2015 (UTC)
I feel like there should be an indicator somewhere that removing the udev hook will render UUID references uselessFor people like me, except I've had that problem before and knew how to recover quickly. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 07:12, 24 July 2012 (UTC)
+
 
* Hrmm? UUID= and LABEL= references are designed to still "just work". Look at resolve_device() in /usr/lib/initcpio/init_functions. blkid is used to try and immediately resolve the UUID to a block device. If and only if udev is involved, the UUID is translated to a /dev/disk path which can be waited on by poll_device (since the symlink may eventually show up). What you '''don't''' get without udev is automatic module insertion, which may cause '''all''' block device references to be useless ;) [[User:Falconindy|Falconindy]] ([[User talk:Falconindy|talk]]) 21:59, 26 July 2012 (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. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 4:32, 12 February 2015 (UTC)
:: I may need some time to wrap my head around this, will have to re-read 'early userspace' articles. I remember having this issue in Mandriva between upgrades, but probably unrelated. Ultimate goal is shooting for <12 second boot times on SATA or USB drive. Custom kernel with all required modules built-in. [[User:T1nk3r3r|T1nk3r3r]] ([[User talk:T1nk3r3r|talk]]) 18:33, 27 July 2012 (UTC)
+
 
 +
::Thank you for your information [[User:Kynikos|Kynikos]]. I'll be contributing these changes very soon. [[User:Grazzolini|Grazzolini]] ([[User talk:Grazzolini|talk]]) 12:54, 12 February 2015 (UTC)
 +
 
 +
== Mark /usr with a passno of {{ic|2}}, not {{ic|0}} ==
 +
 
 +
[[mkinitcpio#/usr as a separate partition]] firmly suggests to mark {{ic|/usr}} with a {{ic|passno}} of {{ic|0}} in {{ic|/etc/fstab}}. The way I understand {{ic|man fstab}}, {{ic|2}} is the correct number for the task. Am I wrong? [[User:Regid|Regid]] ([[User talk:Regid|talk]]) 19:09, 6 April 2017 (UTC)
 +
: It also suggests adding the {{ic|fsck}} hook to your config. Seeing as the regular fsck binaries reside on the {{ic|/usr}} partition, this is needed to actually make it possible to fsck it at startup. The entry in {{ic|/etc/fstab}} should thus be {{ic|0}}. [[User:Koneu|Koneu]] ([[User talk:Koneu|talk]]) 07:27, 7 April 2017 (UTC)
 +
::I see your point about the binaries residing on /usr. Still, with a passno of {{ic|0}} you set no automatic fsck at all, don't you? Would you set passno for / to {{ic|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 /.
 +
::[[User:Regid|Regid]] ([[User talk:Regid|talk]]) 10:12, 7 April 2017 (UTC)
 +
 
 +
== Talking about LUKS/LVM with sd-encrypt example ==
 +
Formerly there was a [https://wiki.archlinux.org/index.php?title=Mkinitcpio&diff=493888&oldid=492088 link to the forum] that was ambiguous about where the UUID were generated from. [[User:enckse|enckse]] documented clearly the same use case within this page, which was reverted by [[User:Lahwaacz|Lahwaacz]] in [https://wiki.archlinux.org/index.php?title=Mkinitcpio&diff=493938&oldid=493934 this change]. The [https://wiki.archlinux.org/index.php?title=Mkinitcpio&oldid=493938 current edit] of the page removes a reference to the forum post entirely. Where should the writeup from [[User:enckse|enckse]] be placed? - [[User:storrgie|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 [https://wiki.archlinux.org/index.php/Persistent_block_device_naming#by-uuid relevant page]. [[User:Jasonwryan|Jasonwryan]] ([[User talk: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? - [[User:storrgie|storrgie]] 22:25, 23 October 2017 (UTC)
 +
::: Then that relevant factoid belongs on the [https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration dm-crypt page] page. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 22:39, 23 October 2017 (UTC)
 +
:::: I've tried to place it in an [https://wiki.archlinux.org/index.php?title=Dm-crypt/System_configuration&diff=493944&oldid=488939 appropriate place on that page], please advise. - [[User:storrgie|storrgie]] 22:50, 23 October 2017 (UTC)
 +
:::::I said *not* the entire tutorial, just the relevant snippet about locating the correct uuids. [[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 23:20, 23 October 2017 (UTC)
 +
:::::: It'd be nice to have a proposed modification rather than just slapping the revert button. - [[User:storrgie|storrgie]] 23:41, 23 October 2017 (UTC)
 +
:::::::[[user:enckse|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:
 +
:::::::* mkinitcpio hooks: [[dm-crypt/System_configuration#mkinitcpio]] (two variants, base and systemd)
 +
:::::::* bootloader config: [[dm-crypt/System_configuration#Using_encrypt_hook]] (for the base hook) and [[dm-crypt/System_configuration#Using_sd-encrypt_hook]] (for the systemd hook) - the second section ''explains'' what the {{ic|rd.luks.*}} parameters actually do, this cannot be found in the forum post
 +
:::::::* If you don't know how to get the UUIDs, read the [[Persistent block device naming]] page - it is linked multiple times from [[dm-crypt/System configuration]]. There is no point to include a full example of {{ic|lsblk -f}} everywhere.
 +
:::::::Though I must admit, that I can't find the {{ic|rd.lvm.lv}} 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.
 +
:::::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:25, 24 October 2017 (UTC)
 +
:::::::: {{ic|rd.lvm.lv}} seems to be a [https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_lvm dracut] specific thing. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:26, 29 October 2017 (UTC)
 +
:::::::: [https://wiki.archlinux.org/index.php?title=Mkinitcpio&diff=494191&oldid=493938] confuses me. Is {{ic|/etc/crypttab}} meant to be {{ic|/etc/crypttab}} on real root or {{ic|/etc/crypttab}} in initramfs (i.e. {{ic|/etc/crypttab.initramfs}} on real root)? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 13:39, 29 October 2017 (UTC)
 +
:::::::::Since the snippet is from the {{man|8|systemd-cryptsetup-generator}} man page, I'd say it's the root where ''systemd-cryptsetup-generator'' is run. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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 {{ic|/etc/crypttab}} on real root)? Using  {{ic|/etc/crypttab.initramfs}} is far simpler than messing around with all those {{ic|rd.luks.}} and {{ic|luks.}} parameters. -- [[User:nl6720|nl6720]] ([[User talk: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]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:31, 29 October 2017 (UTC)
 +
 
 +
== Improvements for the Common hooks table and section about systemd hook ==
 +
 
 +
I find the ''Common hooks'' table extremely useful on getting some information about the {{Pkg|mkinitcpio}} hooks, especially when it comes to '''systemd''' hook compatibility, so I started to improving it, especially as some info seemed to be missing or incomplete. So far I added the note about the modules missing from the table that are included in {{Pkg|initramfs}} package and noted the {{Pkg|btrfs-progs}} for '''btrfs''' hook (it was noted only in ''Runtime'', even if package hosts files for both) and what it seems {{Pkg|mkinitcpio-nfs-utils}} requirement for '''net''' hook – although I'm not 100% sure about the last one, as the package wasn't installed on any of my Arch machines, so I just took a quick look at the repository in browser.
 +
 
 +
Next thing that got me confused was the ''Installation'' and ''Runtime'' tables. I realized that ''Installation'' must actually mean the ''Build'' as that's how the hooks are separated and took a look at what is included in {{ic|/usr/lib/initcpio/install/}} and {{ic|/usr/lib/initcpio/hooks/}} respectively. I found out that while most of the info is accurate (and despite '''resume''' hook being present in {{ic|install/}} it indeed seems it only calls for runtime hook) there are some discrepancies – in {{ic|hooks/}} there seems to be no '''mdadm_udev''' hook, nor '''fsck''' hook. Also, while some busybox ('''base''') hooks have their ''Runtime'' equivalents, this is not in case for '''sd-''' equivalents or '''systemd's''' equivalent for the '''udev''', '''usr''' and '''resume''' (see below).
 +
 
 +
Which brings me to the final point: using '''systemd''' in place of default '''udev''' and '''base'''. It is barely documented on wiki, a bit better on it's help entry, but have been covered in other places. I have been doing that on my machine for a while but are not sure of the explicit benefits of this. I haven't noticed major changes and default {{ic|mkinitcpio.conf}} doesn't even mention it. The table covers the systemd equivalents, but I think a separate section explaining this could be helpful – maybe I just haven't found it yet and it is documented somewhere on wiki, but IMO it should at least be noted near that table, as it's not mentioned anywhere prior it on that page, other the '''Related articles''' and the expansion note. Also, it took me a while to figure the busybox/systemd meanings as they are confusing. Busybox is not mentioned anywhere in the page prior the table, so it either needs prior knowledge or looking at external sources, like [https://web.archive.org/web/20150430223035/http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ /dev/brain0 &raquo; Blog Archive &raquo; Early Userspace in Arch Linux] linked at the beginning. The note for '''base''' to "Always keep this hook as the first hook unless you know what you are doing." on the wiki and {{ic|mkinitcpio -H base}} doesn't explain that it is safe to remove it and systemd's doesn't span towards '''base''' in the table. The only clue is "Provides a busybox recovery shell when using systemd hook." note and only {{ic|mkinitcpio -H systemd}} clears the situation – i.e. the fact that the base can be safely removed, if one doesn't need the recovery shell. It would be nice to explain systemd's hook meaning a little in this wiki page, and would be great if someone more knowledgeable help with that, as I'm only inexperienced tinkerer :).
 +
 
 +
[[User:Faalagorn|Faalagorn]] ([[User talk:Faalagorn|talk]]) 03:26, 28 January 2018 (UTC)
 +
:Thanks for improving. I have slightly different question. Does base hook really provide rescue shell for systemd? Last time I tried to switch to systemd I noticed there is no way to get into rescue shell if something goes wrong. That's why I reverted back to busybox. --[[User:Mxfm|Mxfm]] ([[User talk:Mxfm|talk]]) 06:58, 28 January 2018 (UTC)
 +
 
 +
::Rescue shell should work since systemd-230-5, see {{Bug|36265}}. If it does not work file a new bug report. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:28, 28 January 2018 (UTC)
 +
 
 +
:I removed {{ic|shutdown}} and {{ic|sd-shutdown}} from the expansion template. {{ic|shutdown}} is deprecated[https://lists.archlinux.org/pipermail/arch-dev-public/2013-December/025742.html] and {{ic|sd-shutdown}} should not be added to {{ic|mkinitcpio.conf}}, it's used only by {{ic|mkinitcpio-generate-shutdown-ramfs.service}}.
 +
:As you found out ''Installation'' means stuff in {{ic|/usr/lib/initcpio/install/}} and ''Runtime'' - {{ic|/usr/lib/initcpio/hooks/}}. The ''Runtime'' stuff is custom busybox shell scripts made by Arch devs. {{ic|systemd}}-based hooks don't use any hacky scripts, they uses unit files to start the services so the ''Runtime'' doesn't really apply to {{ic|systemd}}-based hooks. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:44, 28 January 2018 (UTC)
 +
 
 +
:systemd doesn't span towards base in the table because it's not a direct replacement for it, it doesn't provide a recovery shell. There's no need to use systemd hooks unless you have a problem with the busybox hooks, or need functionality that busybox hooks don't provide (e.g. {{Bug|23182}}, {{Bug|42851}}). -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:58, 28 January 2018 (UTC)
 +
 
 +
::Thanks for replying! Since you clarified some of my doubts, I have updated the table to use the ''Build'' instead ''Installation'' notations, since that's what they were referred to previously, and linked to the appropriate sections. I also noted that runtime hooks are only used with busybox init and hopefully clarified the part about inits in the first two columns (maybe that should be rather explained in the sections above though?) – feel free to improve that further though! There's also some standing uncertainess about the '''mdadm_udev''' and '''fsck''' I mentioned, as their are missing their runtime files and are still described in the table? I still think that the systemd section would be worthwhile and a bit clarification on the table – I also found another benefit of systemd hook – additional initrd breakup in {{ic|systemd-analyze}}, [https://bbs.archlinux.org/viewtopic.php?id=210157 see this post and the post it refers to]. Since i was fiddling with things improving the boot time, the extra info is quite helpful for me. There may be some more nuances, too – I was also after [[silent boot]] and while my current systemd initramfs is quiet with just the {{ic|quiet}} and {{ic|loglevel}} [[kernel parameters]], the base + udev hooks are not and probably require more tinkering.[[User:Faalagorn|Faalagorn]] [[User talk:Faalagorn|☎]]/[[Special:Contributions/Faalagorn|✓]] 16:19, 28 January 2018 (UTC)
 +
::'''EDIT:''' There's also issue/question about the '''mdadm''' hook and systemd – according to [https://www.mail-archive.com/arch-projects@archlinux.org/msg03348.html this], '''mdadm''' hook doesn't work and only '''mdadm_udev''' works with '''systemd''' hook. If that still stand, shouldn't mdadm be marked as ''not implemented'', similar to the '''net''' hook for systemd-based init? Also, technically '''systemd''' hook should also have entry in the table I guess, similar how '''base''' (plus '''udev''', '''usr''' and '''resume''') have. [[User:Faalagorn|Faalagorn]] [[User talk:Faalagorn|☎]]/[[Special:Contributions/Faalagorn|✓]] 16:25, 28 January 2018 (UTC)
 +
::: I did some testing with [[minimal initramfs]] with no (cat) compression comparing '''base''' with '''systemd''' hooks boot times. [https://docs.google.com/spreadsheets/d/1xy_480nKj8g17hnWk5NVctQurWRN3K-tdm0lZ6auMVk/edit?usp=sharing Here are my results from 20 boot times]  – it's not professional and done mainly for my own curiosity, but what I found out that while boot time were similar, I spotted the differences – with '''base''' hook EFISTUB loader was constantly 20-21ms faster, which is understandable since the base hook initramfs is physically smaller. However, when using '''systemd''' hook, time spent in userspace was constantly being less for at least a couple ms, averaging at around 27ms less. My boot times with that setup were extremely fast in the first place, running minimal system from an M.2 SSD and hindered mostly by firmware, so the difference may vary by systems, but it seems there's some possible boot time improvements with systemd other than the benefit of splitting initrd from kernel in {{ic|systemd-analyze}}. Also, when using '''systemd''' hook, {{ic|systemd-analyze blame}} now lists more services. initrd-* services are unsurprising, but there were also new systemd-fsck-root.service, systemd-modules-load.service and systemd-tmpfile-clean.service – and still time spent in userspace boot process is less. Unfortunately, the [[F2FS]] on that system broke with ''can't find valid checkpoint'' error when I uncleanly shut the system down, which according to sources found online is irreparable and relatively common lately, so I won't test it further with F2FS, especially as I'm not gonna trust my partition to F2FS anyime soon, but I'll see how it'll be with regular ext4. I may also get to writing a section about systemd-based initramfs unless there's some opposition or someone else is working on it and probably update the [[Minimal initramfs]] page as well. [[User:Faalagorn|Faalagorn]] [[User talk:Faalagorn|☎]]/[[Special:Contributions/Faalagorn|]] 13:11, 30 January 2018 (UTC)

Latest revision as of 13:12, 30 January 2018

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 rd.lvm.lv 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)
rd.lvm.lv 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)

Improvements for the Common hooks table and section about systemd hook

I find the Common hooks table extremely useful on getting some information about the mkinitcpio hooks, especially when it comes to systemd hook compatibility, so I started to improving it, especially as some info seemed to be missing or incomplete. So far I added the note about the modules missing from the table that are included in initramfs package and noted the btrfs-progs for btrfs hook (it was noted only in Runtime, even if package hosts files for both) and what it seems mkinitcpio-nfs-utils requirement for net hook – although I'm not 100% sure about the last one, as the package wasn't installed on any of my Arch machines, so I just took a quick look at the repository in browser.

Next thing that got me confused was the Installation and Runtime tables. I realized that Installation must actually mean the Build as that's how the hooks are separated and took a look at what is included in /usr/lib/initcpio/install/ and /usr/lib/initcpio/hooks/ respectively. I found out that while most of the info is accurate (and despite resume hook being present in install/ it indeed seems it only calls for runtime hook) there are some discrepancies – in hooks/ there seems to be no mdadm_udev hook, nor fsck hook. Also, while some busybox (base) hooks have their Runtime equivalents, this is not in case for sd- equivalents or systemd's equivalent for the udev, usr and resume (see below).

Which brings me to the final point: using systemd in place of default udev and base. It is barely documented on wiki, a bit better on it's help entry, but have been covered in other places. I have been doing that on my machine for a while but are not sure of the explicit benefits of this. I haven't noticed major changes and default mkinitcpio.conf doesn't even mention it. The table covers the systemd equivalents, but I think a separate section explaining this could be helpful – maybe I just haven't found it yet and it is documented somewhere on wiki, but IMO it should at least be noted near that table, as it's not mentioned anywhere prior it on that page, other the Related articles and the expansion note. Also, it took me a while to figure the busybox/systemd meanings as they are confusing. Busybox is not mentioned anywhere in the page prior the table, so it either needs prior knowledge or looking at external sources, like /dev/brain0 » Blog Archive » Early Userspace in Arch Linux linked at the beginning. The note for base to "Always keep this hook as the first hook unless you know what you are doing." on the wiki and mkinitcpio -H base doesn't explain that it is safe to remove it and systemd's doesn't span towards base in the table. The only clue is "Provides a busybox recovery shell when using systemd hook." note and only mkinitcpio -H systemd clears the situation – i.e. the fact that the base can be safely removed, if one doesn't need the recovery shell. It would be nice to explain systemd's hook meaning a little in this wiki page, and would be great if someone more knowledgeable help with that, as I'm only inexperienced tinkerer :).

Faalagorn (talk) 03:26, 28 January 2018 (UTC)

Thanks for improving. I have slightly different question. Does base hook really provide rescue shell for systemd? Last time I tried to switch to systemd I noticed there is no way to get into rescue shell if something goes wrong. That's why I reverted back to busybox. --Mxfm (talk) 06:58, 28 January 2018 (UTC)
Rescue shell should work since systemd-230-5, see FS#36265. If it does not work file a new bug report. -- nl6720 (talk) 09:28, 28 January 2018 (UTC)
I removed shutdown and sd-shutdown from the expansion template. shutdown is deprecated[2] and sd-shutdown should not be added to mkinitcpio.conf, it's used only by mkinitcpio-generate-shutdown-ramfs.service.
As you found out Installation means stuff in /usr/lib/initcpio/install/ and Runtime - /usr/lib/initcpio/hooks/. The Runtime stuff is custom busybox shell scripts made by Arch devs. systemd-based hooks don't use any hacky scripts, they uses unit files to start the services so the Runtime doesn't really apply to systemd-based hooks. -- nl6720 (talk) 09:44, 28 January 2018 (UTC)
systemd doesn't span towards base in the table because it's not a direct replacement for it, it doesn't provide a recovery shell. There's no need to use systemd hooks unless you have a problem with the busybox hooks, or need functionality that busybox hooks don't provide (e.g. FS#23182, FS#42851). -- nl6720 (talk) 09:58, 28 January 2018 (UTC)
Thanks for replying! Since you clarified some of my doubts, I have updated the table to use the Build instead Installation notations, since that's what they were referred to previously, and linked to the appropriate sections. I also noted that runtime hooks are only used with busybox init and hopefully clarified the part about inits in the first two columns (maybe that should be rather explained in the sections above though?) – feel free to improve that further though! There's also some standing uncertainess about the mdadm_udev and fsck I mentioned, as their are missing their runtime files and are still described in the table? I still think that the systemd section would be worthwhile and a bit clarification on the table – I also found another benefit of systemd hook – additional initrd breakup in systemd-analyze, see this post and the post it refers to. Since i was fiddling with things improving the boot time, the extra info is quite helpful for me. There may be some more nuances, too – I was also after silent boot and while my current systemd initramfs is quiet with just the quiet and loglevel kernel parameters, the base + udev hooks are not and probably require more tinkering.Faalagorn / 16:19, 28 January 2018 (UTC)
EDIT: There's also issue/question about the mdadm hook and systemd – according to this, mdadm hook doesn't work and only mdadm_udev works with systemd hook. If that still stand, shouldn't mdadm be marked as not implemented, similar to the net hook for systemd-based init? Also, technically systemd hook should also have entry in the table I guess, similar how base (plus udev, usr and resume) have. Faalagorn / 16:25, 28 January 2018 (UTC)
I did some testing with minimal initramfs with no (cat) compression comparing base with systemd hooks boot times. Here are my results from 20 boot times – it's not professional and done mainly for my own curiosity, but what I found out that while boot time were similar, I spotted the differences – with base hook EFISTUB loader was constantly 20-21ms faster, which is understandable since the base hook initramfs is physically smaller. However, when using systemd hook, time spent in userspace was constantly being less for at least a couple ms, averaging at around 27ms less. My boot times with that setup were extremely fast in the first place, running minimal system from an M.2 SSD and hindered mostly by firmware, so the difference may vary by systems, but it seems there's some possible boot time improvements with systemd other than the benefit of splitting initrd from kernel in systemd-analyze. Also, when using systemd hook, systemd-analyze blame now lists more services. initrd-* services are unsurprising, but there were also new systemd-fsck-root.service, systemd-modules-load.service and systemd-tmpfile-clean.service – and still time spent in userspace boot process is less. Unfortunately, the F2FS on that system broke with can't find valid checkpoint error when I uncleanly shut the system down, which according to sources found online is irreparable and relatively common lately, so I won't test it further with F2FS, especially as I'm not gonna trust my partition to F2FS anyime soon, but I'll see how it'll be with regular ext4. I may also get to writing a section about systemd-based initramfs unless there's some opposition or someone else is working on it and probably update the Minimal initramfs page as well. Faalagorn / 13:11, 30 January 2018 (UTC)