[ISSUE] [RFC] dracut vs mkinitcpio

[ISSUE] [RFC] dracut vs mkinitcpio

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 305 bytes --]

New issue by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/30813

Description:
What are the main benefits of using `dracut` vs `mkinitcpio`?

For an encrypted setup, is it enough to add the `keyboard`, `keymap` and `encrypt` hooks to `mkinitcpio.conf`?

Thanks.

Re: [RFC] dracut vs mkinitcpio

[ericonr]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-839706638

Comment:
The best mkinitcpio documentation is from Arch Linux. They support systemd-less initramfs, so it should be fully applicable to void. I'm saying this because I don't have experience with mkinitcpio in void myself, and don't remember my Manjaro setup.

As for features, I'm not sure. Choosing an initramfs generator seems to be more about picking one and sticking to it than extensive technical advantages, but I could be wrong. Could investigate git history to see when drafut became default.

Re: [RFC] dracut vs mkinitcpio

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-839727218

Comment:
> They support systemd-less initramfs, so it should be fully applicable to void.
As for `dracut`, the attitude seems to be: focus their resources to further integrate with and optimize for systemd.

Re: [RFC] dracut vs mkinitcpio

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-839727218

Comment:
> They support systemd-less initramfs, so it should be fully applicable to void.

As for `dracut`, the attitude seems to be: focus their resources to further integrate with and optimize for systemd.

Re: [RFC] dracut vs mkinitcpio

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-839727218

Comment:
> They support systemd-less initramfs, so it should be fully applicable to void.

As for `dracut`, the attitude seems to be: focus their resources to further integrate with and optimize for systemd.

@ahesford 

Re: [RFC] dracut vs mkinitcpio

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-839756805

Comment:
I prefer mkinitcpio to dracut. It is much simpler. In dracut, there are multiple levels of hooks that modules can inject, but some hooks aren't guaranteed to run even once. The `console_init.sh` hook in the `i18n` module, for example, will never be run if other "critical" hooks finish too quickly. I opened an issue about this and was told to bugger off because I don't use systemd.

One of these days, I intend to investigate a full-featured migration to mkinitcpio in Void, but it's a low-priority task that keeps getting bumped.

Re: [RFC] dracut vs mkinitcpio

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-840499816

Comment:
What should be changed in order for `XBPS` to use `mkinitcpio` instead of `dracut`?

Re: [RFC] dracut vs mkinitcpio

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 261 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-840499816

Comment:
What should be changed in order for `XBPS` to use `mkinitcpio` instead of `dracut`?
I mean as far as `XBPS` settings go.

Re: [RFC] dracut vs mkinitcpio

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 265 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-840527763

Comment:
Nothing, other than changing the dependency of `base-system`. They both just hook into the `/etc/kernel.d` hooking system.

Re: [RFC] dracut vs mkinitcpio

[Duncaen]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

New comment by Duncaen on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-840527763

Comment:
Nothing, other than changing the dependency of `base-system`. They both just hook into the `/etc/kernel.d` hooking system.

Not sure if there is a nice way to do this change, if we don't add `replaces=dracut>=someversion`, then users will have two initramfs for each kernel until they remove orphaned packages.
If we just replace dracut then users who actually configured dracut to work with their system, but not mkinitcpio then we are going to somewhat break their system or cause an inconvenience.

Re: [RFC] dracut vs mkinitcpio

[travankor]

[-- Attachment #1: Type: text/plain, Size: 162 bytes --]

New comment by travankor on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-842340417

Comment:
@dkwo try #29434 

Re: [RFC] dracut vs mkinitcpio

[travankor]

[-- Attachment #1: Type: text/plain, Size: 190 bytes --]

New comment by travankor on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-842340417

Comment:
@dkwo You could try #29434 if you would like.

Re: [RFC] dracut vs mkinitcpio

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-842446230

Comment:
@travankor Good to know, thanks.
It does not require any hooks to deal with encrypted partition, correct?

Re: [RFC] dracut vs mkinitcpio

[travankor]

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]

New comment by travankor on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-842954103

Comment:
Yes, no hooks are used currently. Most features are built in by default.

Re: [RFC] dracut vs mkinitcpio

[furryfixer]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

New comment by furryfixer on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-846691377

Comment:
While I am sure mkinitcpio will be around for a long time, it has been inconsistently maintained, and Giancarlo Razzolini, who is listed as Arch maintainer, seems less than enthused.  He has suggested switching Arch to dracut as default.

Re: [RFC] dracut vs mkinitcpio vs booster

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-871204431

Comment:
After some trial time, my two cents here go to `booster`: it is simple, works well, and the developer is willing to debug non-systemd issues. Actually, they just helped solve an issue with runit.

Re: [RFC] dracut vs mkinitcpio vs booster

[q66]

[-- Attachment #1: Type: text/plain, Size: 184 bytes --]

New comment by q66 on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-871265183

Comment:
booster is non-portable so it's not an option

Re: [RFC] dracut vs mkinitcpio vs booster

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 191 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-872017161

Comment:
@q66 Could you clarify your definition of portable?

Re: [RFC] dracut vs mkinitcpio vs booster

[Johnnynator]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

New comment by Johnnynator on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-872077201

Comment:
It us unportable, because it is written in go, e.g. we currently do not have go properly on 32bit ppc and mips.

Re: [RFC] dracut vs mkinitcpio vs booster

[q66]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

New comment by q66 on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-872136243

Comment:
gccgo is a joke/toy, and official go is only available on x86/arm/aarch64/ppc64le, so yeah, it's pretty non-portable 

Re: [RFC] dracut vs mkinitcpio vs booster

[q66]

[-- Attachment #1: Type: text/plain, Size: 321 bytes --]

New comment by q66 on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-872136243

Comment:
gccgo is a joke/toy, and official go is only available on x86/arm/aarch64/ppc64le, so yeah, it's pretty non-portable 

I don't want a google language anywhere near the base system 

Re: [RFC] dracut vs mkinitcpio vs booster

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-872161655

Comment:
Part of this discussion gets charged because we start thinking about where we'd go when dracut becomes completely hostile to anything but systemd. Every release seems to take us closer to that point.

I now think the best thing we can do is try to decouple packages from a single initramfs generator. 876b6ed3a4da006639908794bff4eeaeb0f123eb is a start, replacing dracut-specific post-install scripts with a common XBPS trigger that is currently aware of mkinitcpio and dracut. Somebody can add booster, initramfs-tools, whatever to that trigger as needed.

The only other issue that remains is how to cleanly handle multiple installed generators. On some systems, I've been using mkinitcpio to ensure there is a clean transitional path. However, ZFSBootMenu still requires dracut. Having both installed means multiple kernel hooks compete (mkinitcpio would win here) unless I `noextract` the hooks I don't want. This works fine for people who know to do it, but we really need a method for multiple kernel hooks to coexist without all of them firing. I see two possibilities:
1. Every kernel hook is aware of `/etc/default/initramfs-regenerate` used by the XBPS trigger and will turn itself into a no-op if the configured generator does not agree with the one in the hook, or
2. We centralize the kernel hook, knowing how to create an initramfs for each generator and choosing the right one based on the configuration.
The first option provably violates DRY, but the second doesn't scale well beyond a handful of generators. No problem; we should never really have more than a handful available anyway.  I think (2) is a bit cleaner.

With the hook issue resolved, we can probably just define a virtual provided by all the generators. People can then just use what they want with no problems. The last issue is choosing a default provider, but that should obviously be dracut for a long time because we have a lot of inertia.

Re: [RFC] dracut vs mkinitcpio vs booster

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 177 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/30813#issuecomment-872184132

Comment:
I see, thanks for the clarifications.

Re: [ISSUE] [CLOSED] [RFC] initramfs

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

Closed issue by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/30813

Description:
What are the main benefits of using `dracut` vs `mkinitcpio`?

For an encrypted setup, is it enough to add the `keyboard`, `keymap` and `encrypt` hooks to `mkinitcpio.conf`?

Thanks.