Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/01/2019 05:06 PM, Eli Schwartz via arch-general wrote: > 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. Now that does not bode well as something to build your setup around. I have dracut working fine on openSUSE, so I know it will work, but I sure haven't had any problems with the current way Arch does it. Unless there is a reliable (and responsive) upstream, I don't see the benefit (or wisdom) of patching a project that is somewhat "on-hold" just to say we have dracut and moving to it. SuSE has a lot of resources to direct toward the issue. Personally I've always found the Arch KISS philosophy the better approach. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 11:27 PM, Giancarlo Razzolini wrote: > > > xz is much slower than gzip, and the kernel does not support zstd. > Right - facebook brought it up again a few months ago, thread went quiet and I incorrectly assumed it was actually mainlined - but you're right it isn't. https://lkml.org/lkml/2019/6/10/725 Thanks!
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
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 pgprFrL3Qs2Yd.pgp Description: PGP signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 11:16 PM, Genes Lists via arch-general wrote: > > gene > Clearly image size and compression both likely impact boot time. An interesting comparison might be running systemd-analyze blame after booting with and with hostonly and with and without compression. Anyone have a comparison handy?
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
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
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 7:31 PM, Giancarlo Razzolini wrote: > 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 Yeh, that makes sense - plus its very easy to add to dracut.conf > called twice, once with -H and once without, to create the > regular/fallback images. 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. > > 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. Good catch - i missed that. 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. Also, is it time to switch from gzip to xz or even to zstd yet? gene > > Regards, > Giancarlo Razzolini
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
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 pgptC3g9x8lIo.pgp Description: PGP signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 7:05 PM, Genes Lists via arch-general wrote: > Only suggestion I'd make is adding "--mdadmconf" perhaps by default - To clarify, I mean in dracut.conf - so I should probably have said mdadmconf="yes" ... anyway, thanks again. gene
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
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
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
Em novembro 3, 2019 12:45 Genes Lists via arch-general escreveu: 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? 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 pgpBrFDffKObr.pgp Description: PGP signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
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?
