Em outubro 31, 2019 15:11 Geo Kozey escreveu:

What was the reason for not using kernel-install[1] standard instead of all of those Arch's exclusive hooks again??

https://www.freedesktop.org/software/systemd/man/kernel-install.html

Yours sincerely

G. K.

There are several reasons for not using it. It's overly complex, it does a lot of assumptions for you, among other things. That doesn't mean it *can't* be used by the users. We are taking baby steps on making the booting process on Arch overall more flexible. You can *right now* completely override the mkinitcpio hooks and, install and deal with the kernel *any* way you want. Want to not use /boot? Can do. Want to stuff everything on /efi? Can do. Want a hook that will build your efistub and update entries? Can do. This update opens up lots of possibilities, while also maintaining (some) backward compatibility. I'm planning a few changes [0] to mkinitcpio, to make this even more flexible. Also, as I've mentioned, dracut should receive soon, hooks similar to those mkinitcpio did, with a few differences of course. But, since the most important part for keeping most user's systems booting is the actual kernel installation, if you opt to override either the mkinitcpio hooks or dracut's, it will be your job to make sure you install the kernel to wherever you want it. Regards, Giancarlo Razzolini [0] https://github.com/archlinux/mkinitcpio/issues

---------------------------------------- From: Giancarlo Razzolini <grazzolini@archlinux.org> Sent: Thu Oct 31 19:30:42 CET 2019 To: General Discussion about Arch Linux <arch-general@archlinux.org>, Geo Kozey <geokozey@mailfence.com> Subject: Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod

There are several reasons for not using it. It's overly complex, it does a lot of assumptions for you, among other things. That doesn't mean it *can't* be used by the users. We are taking baby steps on making the booting process on Arch overall more flexible.

You can *right now* completely override the mkinitcpio hooks and, install and deal with the kernel *any* way you want. Want to not use /boot? Can do. Want to stuff everything on /efi? Can do. Want a hook that will build your efistub and update entries? Can do. This update opens up lots of possibilities, while also maintaining (some) backward compatibility.

I'm planning a few changes [0] to mkinitcpio, to make this even more flexible. Also, as I've mentioned, dracut should receive soon, hooks similar to those mkinitcpio did, with a few differences of course. But, since the most important part for keeping most user's systems booting is the actual kernel installation, if you opt to override either the mkinitcpio hooks or dracut's, it will be your job to make sure you install the kernel to wherever you want it.

Regards, Giancarlo Razzolini

[0] https://github.com/archlinux/mkinitcpio/issues

Thx, my concern was more about maintenance burden for Arch devs vs relying on dracut + kernel-install combo and call it a day. If devs prefer to work on exclusive service for Arch users then let it be. Yours sincerely G. K.

---------------------------------------- From: Eli Schwartz via arch-general <arch-general@archlinux.org> Sent: Fri Nov 01 23:06:03 CET 2019 To: <arch-general@archlinux.org> Cc: Eli Schwartz <eschwartz@archlinux.org> Subject: Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod

Dracut does not work out of the box (we currently patch it to not use a nonexistent tool, and the same patch is now in upstream master but with no release in sight), and has issues like the tests failing on non-Redhat systems.

Our dracut packager tried to get in touch with the dracut developer, after a lack of success for quite some time it seems that the individual in question was on... parental leave, IIRC? I'm not sure what the current status is.

In such cases using tip of git branch would help.

So the jury is still out on whether dracut or mkinitcpio is more work. ;)

Making dracut work initially may need some work but after that it will just work. There is also 3rd-party initramfs modules developer perspective where coding something once which then will work on all distros (as dracut is supported in fedora/rhel, ubuntu/debian, suse, etc.) makes life easier than having to support each distro separately. Fragmentation is big issue as always. Yours sincerely G. K.

On 10/31/19 2:30 PM, Giancarlo Razzolini via arch-general wrote: ...

... Also, as I've mentioned, dracut should receive soon, hooks similar to those mkinitcpio did, with a few differences of course.

Since Giancarlo brought up dracut in May this year, I've been using this successfully to boot custom built upstream kernels on about 8 different systems, including servers running soft RAID. And it works very, very well - thank you for driving this forward. Giancarlo is there anything that may need changing to boot using dracut going forward?

On 11/3/19 4:02 PM, Giancarlo Razzolini wrote:

I'm as of now writing hooks for dracut to be able to install the kernel, as mkinitcpio does, and I'm considering have a preset config, like mkinicpio, so it gives the user the ability to decide how dracut is ran.

Other than that, given that dracut is slightly different than mkinitcpio, I don't think these hooks should be overworked. On the other hand, the kernel installation will be somewhat inflexible if done only to /boot.

I think initially it'll be like that, but then we can use dracut's configuration for this.

Regards, Giancarlo Razzolini

Thank you ... I really like dracut - it works well. Only suggestion I'd make is adding "--mdadmconf" perhaps by default - though I can see it both ways for those who don't use RAID - if its easy to add that would also be totally fine. Thanks again. gene

Em novembro 3, 2019 21:05 Genes Lists via arch-general escreveu:

Thank you ... I really like dracut - it works well. Only suggestion I'd make is adding "--mdadmconf" perhaps by default - though I can see it both ways for those who don't use RAID - if its easy to add that would also be totally fine.

That would require having dracut depend on mdadm. I think this is something to be done by the user. I plan a simple config/preset per kernel that will be called twice, once with -H and once without, to create the regular/fallback images. Also, I've found out that, for some reason, dracut defaults to creating non-compressed images when nothing is passed, so I'll probably add arguments to make sure they are compressed. Regards, Giancarlo Razzolini

On 11/3/19 10:59 PM, Genes Lists via arch-general wrote:

Not sure what value a fallback image actualy provides at this point? It takes more space and I don't see it adding much value.

Didn't think enough - the host only image might well be faster to boot (being smaller) - but I have not benchmarked the benefit. Be curious how much faster booting with the host-only image would be. Anything else I've missed for having this? gene

Em novembro 4, 2019 0:59 Genes Lists via arch-general escreveu:

Yeh, that makes sense - plus its very easy to add to dracut.conf

Yes. dracut supports /etc/dracut.d, so there's where they recommend to put settings.

Been thinking about that - I've switched to building without -H and not creating a fallback image - I've also switched to signing all modules (in and out of tree).

Not sure what value a fallback image actualy provides at this point? It takes more space and I don't see it adding much value.

While I agree that they might not be needed that much, it's a good thing to have, even if you don't use it. I can ship with it enabled and then users can remove it.

I that that we would be better with compression being put in dracut.conf. Be more flexible that way than the command line which I assume overides dracut.conf - so a lot less flexible.

Yes, that's the idea.

Also, is it time to switch from gzip to xz or even to zstd yet?

xz is much slower than gzip, and the kernel does not support zstd. Regards, Giancarlo Razzolini

On 10/31/19 2:11 PM, Geo Kozey via arch-general wrote:

What was the reason for not using kernel-install[1] standard instead of all of those Arch's exclusive hooks again??

https://www.freedesktop.org/software/systemd/man/kernel-install.html

What was the reason for suggesting to use kernel-install non-standard Fedora tool that does gross things in a gross way instead of "all those tools" (all one of them) which do the exact same thing in a more KISS manner that respects user choice, makes it clear what you're using and when you're using it, and helps track files properly in pacman? I don't understand your loaded question, but this game of "let's assume things and then yell at people for doing things the same way they worked for many many years" sure is fun! P.S. Put down your question mark key. There's no need to act quite *that* shocked that no one drank the Fedora kool-aid. *steps off soapbox* -- Eli Schwartz Bug Wrangler and Trusted User

On 10/31/19 3:46 PM, Giancarlo Razzolini wrote:

Hi Eli,

This is totally uncalled for. Even though I agree that kernel-install is *not* that great, there's no need to be aggressive.

The question, even if phrased not in the best way, is a legitimate one.

Didn't seem like much of a question to me. As far as I'm aware, there is no actual blocker to it, we even package it as one of the collection of tools made available by systemd so you literally cannot avoid having it available as it's a mandatory part of base. (The kernel is not mandatory, and mkinitcpio is not mandatory, but kernel-install is mandatory.) To aid such people, both mkinitcpio and dracut install relevant files to /usr/lib/kernel/install.d/ ... If people think kernel-install is an interesting technology which they would like to try out, that is fine. If people think kernel-install is literally the best ever and they must use it, that's fine too. I personally don't feel that way, and would rather have the option to skip the use of kernel-install, and that is fine too. I'm a bit skeptical, though, of posts which feature, essentially, "I notice Arch Linux does not bless kernel-install as the official kernel method of Arch Linux and request that you justify your decision to not use documented standards[0] and instead use your exclusivist Arch Linux hooks which merit multiple exclamation marks worth of surprise, because gosh is this surprisingly surprising". So I *inverted the question*. (I acknowledge I may have gotten a bit exaggerated in the process... I apologize. OTOH, I didn't quite intend my statements about kernel-install 100% seriously.) -- Eli Schwartz Bug Wrangler and Trusted User [0] Putting something in a manpage doesn't necessarily make it a standard, even if you find it really useful and enjoyable to use.

On Thu, 31 Oct 2019 at 14:55, Giancarlo Razzolini <grazzolini@archlinux.org> wrote:

Em outubro 31, 2019 9:46 Damjan Georgievski via arch-general escreveu:

...

Can someone explain in better detail the changes in * kmod 26-3 * mkinitcpio 27-1 * linux 5.3.8.1-1 around packaging and pacman hooks?

I can see there's some reorganization of the hooks and scripts, and the kernel package no longer installing directly to /boot (which is a welcome change, the kernel is now only in /usr/lib/modules/5.3.8-arch1-1/vmlinuz) but it's not easy for me to reverse-understand what the bash scripts do exactly.

I'm asking because I also use pacman hooks on the kernel and some other files in order to create my combined kernel+initramfs+cmdline UEFI executable signed for secure-boot, and it seems I'll have to adopt to a newer setup.

Hi Damjan,

The kernel does not install itself anymore to /boot, as you've noticed. But, the mkinitcpio hook does that. For now, we are replicating the same behavior as before, but with a little more flexibility.

I'm working on dracut hooks for doing a similar job, but the idea is that we eventually will be more flexible with our booting, giving the user more options. Keep an eye on the Arch announce mailing list, as well as the news on the Arch site.

As for your hooks, we made so that the mkinitcpio hook runs at the same step the previous linux hook would. So, there shouldn't be any incompatibilities. But, it depends on what your hooks are. Also, you can completely override the mkinitcpio hooks by linking their filenames to /dev/null on /etc/pacmand.d/hooks directory. But you'll be left doing the kernel installation on your own.

Thanks for the info Giancarlo, it's true that my hook works as before (I've tested that), but even my original hook was suboptimal anyway, since I needed to define one hook per kernel package. I'm wondering if I can make a more general hook, for example triggering on usr/lib/modules/*/pkgbase (or vmlinuz?) - is that the recommended way now? -- damjan