Re: [arch-general] [arch-dev-public] [PATCH 1/1] move initramfs generation from install script to pacman hook
On 19-05-2016 00:20, Sébastien Luttringer wrote:
Could we use a prefix convention to order our hooks? It's usefull to build modules before building initramfs and eventually run grub update at the end.
Not sure triggering grub update automagically is a good idea, I maintain grub.cfg myself and I'm sure more people do the same. I'd guess everyone that maintains their own grub.cfg would really appreciate not having a bad surprise after a kernel update. -- Mauro Santos
On Thu, 19 May 2016 13:13:51 +0100 Mauro Santos <registo.mailling@gmail.com> wrote:
On 19-05-2016 00:20, Sébastien Luttringer wrote:
Could we use a prefix convention to order our hooks? It's usefull to build modules before building initramfs and eventually run grub update at the end.
Not sure triggering grub update automagically is a good idea, I maintain grub.cfg myself and I'm sure more people do the same.
I'd guess everyone that maintains their own grub.cfg would really appreciate not having a bad surprise after a kernel update.
I don't think he means as part of a package, but as something that the sysadmin sets up. It's just an example of how ordering hooks can be helpful.
On 19-05-2016 13:33, Doug Newgard wrote:
On Thu, 19 May 2016 13:13:51 +0100 Mauro Santos <registo.mailling@gmail.com> wrote:
On 19-05-2016 00:20, Sébastien Luttringer wrote:
Could we use a prefix convention to order our hooks? It's usefull to build modules before building initramfs and eventually run grub update at the end.
Not sure triggering grub update automagically is a good idea, I maintain grub.cfg myself and I'm sure more people do the same.
I'd guess everyone that maintains their own grub.cfg would really appreciate not having a bad surprise after a kernel update.
I don't think he means as part of a package, but as something that the sysadmin sets up. It's just an example of how ordering hooks can be helpful.
The way the sentence was worded I understood that in the future it could possibly be implemented as part of a package and raised the concern. When given as an example, it's a perfectly reasonable example of what a sysadmin might want to order properly :) Sorry for the noise. -- Mauro Santos
On Thu, May 19, 2016 at 2:13 PM, Mauro Santos <registo.mailling@gmail.com> wrote:
On 19-05-2016 00:20, Sébastien Luttringer wrote:
Could we use a prefix convention to order our hooks? It's usefull to build modules before building initramfs and eventually run grub update at the end.
Not sure triggering grub update automagically is a good idea, I maintain grub.cfg myself and I'm sure more people do the same.
I'd guess everyone that maintains their own grub.cfg would really appreciate not having a bad surprise after a kernel update.
I didn't know Arch didn't overwrite/regenerate grub.cfg, but because distros usually do, I use syslinux instead. Good to know grub is an options.
On 19.05.2016 22:24, Carsten Mattner wrote:
I'd guess everyone that maintains their own grub.cfg would really appreciate not having a bad surprise after a kernel update.
But as a sysadmin I can configure my own hooks in /etc/hooks, right? So, I could optionally add a hook which upates grub.
On Thu, May 19, 2016 at 2:13 PM, Mauro Santos <registo.mailling@gmail.com> wrote:
On 19-05-2016 00:20, Sébastien Luttringer wrote:
Could we use a prefix convention to order our hooks? It's usefull to build modules before building initramfs and eventually run grub update at the end.
Not sure triggering grub update automagically is a good idea, I maintain grub.cfg myself and I'm sure more people do the same.
I'd guess everyone that maintains their own grub.cfg would really appreciate not having a bad surprise after a kernel update.
I second that. Touching bootloader config is a bad idea. For example, in my case, I use arch's syslinux to boot multiple distros (with custom syslinux.cfg), which don't even have a bootloader package. Thx, L. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
participants (5)
-
Carsten Mattner
-
Doug Newgard
-
Leonid Isaev
-
Mauro Santos
-
Stefan Tatschner