[PATCH] boot install: Partially refactor the logic for detecting bootloader

[PATCH] boot install: Partially refactor the logic for detecting bootloader

[Beru Shinsetsu]

While running `make install` after building the kernel and installing
modules on several distros like EndeavourOS, there would be a pretty
little output (To be exact, "Cannot find LILO") due to lack of LILO
bootloader, which is really uncommon for a user to have it while
GRUB is there. So, if LILO doesn't exist, instead of skipping other
bootloaders, check for `grub-mkconfig` using exit status of `which
grub-mkconfig` to see if we have it present in PATH and run it. All
GRUB installs must have it in PATH for other external scripts and
GRUB itself to handle it fine as well.

I have no idea why did the maintainer not consider this, even after
several posts done on several forums without an actual patch. See
appended link for more details on why is this required without
requiring user to run it themselves.

Link: https://serverfault.com/questions/383286/compiling-linux-kernel-make-install-asks-for-lilo-now-what

Also, put the `sync` command to the end of all commands, make sure
all copied files are properly written to disk for all cases, not only
when LILO is not found.

Suggested-by: Alviro Iskandar Setiawan <alviro.iskandar@gnuweeb.org>
Signed-off-by: Beru Shinsetsu <windowz414@gnuweeb.org>
---

  v2 -> v3
  - Properly make use of GRUB config check and execute `echo` for
    when LILO and GRUB are not found only when *both* are missing.
  - Make the exit status check compatible with POSIX shell as
    well.
  - Upon Alviro's suggestion, put `sync` command to the very end,
    to make sure all copied files are properly written to disk
    unconditionally.

  (Link v2: https://t.me/GNUWeeb/552772)
  v1 -> v2
  - Remove use of absolute path for grub-mkconfig check and use
    `which` instead and check its exit status.
  - Change commit message accordingly.
---
 arch/x86/boot/install.sh | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/boot/install.sh b/arch/x86/boot/install.sh
index d13ec1c38640..2007c06dbbdd 100644
--- a/arch/x86/boot/install.sh
+++ b/arch/x86/boot/install.sh
@@ -54,6 +54,11 @@ if [ -x /sbin/lilo ]; then
 elif [ -x /etc/lilo/install ]; then
        /etc/lilo/install
 else
-       sync
-       echo "Cannot find LILO."
+       which grub-mkconfig > /dev/null 2>&1
+       if [ "$?" -eq "0" ]; then
+              grub-mkconfig -o /etc/grub/grub.cfg
+       else
+              echo "Cannot find LILO or GRUB."
+       fi
 fi
+sync
-- 
2.35.1

Re: [PATCH] boot install: Partially refactor the logic for detecting bootloader

[Boris Petkov]

On March 16, 2022 5:32:21 PM UTC, Beru Shinsetsu <windowz414@gnuweeb.org> wrote:
>While running `make install` after building the kernel and installing
>modules on several distros like EndeavourOS, there would be a pretty
>little output (To be exact, "Cannot find LILO") due to lack of LILO
>bootloader, which is really uncommon for a user to have it while
>GRUB is there. 

As a matter of fact I saw this yesterday on one of the test boxes here and was wondering why I am even seeing this. So before we do anything, it'd be prudent to know what has changed recently to cause this error message to happen. Because we would have to backport a fix to some kernels probably.

Thx.

-- 
Sent from a small device: formatting sux and brevity is inevitable.

Re: [PATCH] boot install: Partially refactor the logic for detecting bootloader

[Beru Shinsetsu]

On Thu, 2022-03-17 at 12:36 +0000, Boris Petkov wrote:
> On March 16, 2022 5:32:21 PM UTC, Beru Shinsetsu
> <windowz414@gnuweeb.org> wrote:
> > While running `make install` after building the kernel and
> > installing
> > modules on several distros like EndeavourOS, there would be a
> > pretty
> > little output (To be exact, "Cannot find LILO") due to lack of LILO
> > bootloader, which is really uncommon for a user to have it while
> > GRUB is there. 
> 
> As a matter of fact I saw this yesterday on one of the test boxes
> here and was wondering why I am even seeing this.

I guess I had pure luck having this patch seen? xd

> So before we do anything, it'd be prudent to know what has changed
> recently to cause this error message to happen. Because we would have
> to backport a fix to some kernels probably.

To be honest with you, nothing has changed _just recently_ to cause
this error message to come up. It was a long living thing (since the
time LILO check has appeared and the last change to it was in 2007. I
can't find when did the check appear for the first time as Linus
apparently ripped off the whole history from before 2.16.12-rc2.), just
was unseen as most of Linux distros love to ship their own ways to
install kernels... except Arch Linux and distros based on it, as they
have Arch User Repository to automatically compile the kernel locally
and make a PacMan package out of the artifacts using some external
package manager like Yay or Aura. And if you have checked the
ServerFault forum thread I have appended in original commit message,
you can see it was there for really long and has been happening only on
Arch Linux or distros based on it, like EndeavourOS. I have also tested
this out on my environment (I have EndeavourOS on my laptop's HDD and
Ubuntu Budgie on my USB HDD). I get the error message on Endeavour
while I don't on Ubuntu Budgie if I run `make install` without this
patch I made applied. But if I apply this patch then run it, it works
on both.

TL;DR, this was something that has been there since 2.x and wasn't
patched ever since, so here I do as I figured out how it's handled
without requirement of user interaction, through this patch.

Commit ripping off the history from before 2.16.12-rc2: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (Linux-2.6.12-rc2)
Last commit towards LILO check: 47f82189b185bf4b0de4ebce237850e8d3b1d0b6 (broken lilo check on make install)

> Thx.

And I thank you for your attention! :)
-- 
Beru Shinsetsu

Re: [PATCH] boot install: Partially refactor the logic for detecting bootloader

[Boris Petkov]

On March 17, 2022 1:16:26 PM UTC, Beru Shinsetsu <windowz414@gnuweeb.org> wrote:
>I guess I had pure luck having this patch seen? xd

I'm not sure what you mean here??

>To be honest with you, nothing has changed _just recently_ to cause
>this error message to come up.

Well, I saw this on SLE15-SP4 (brand new) yesterday while I haven't seen it on previous service packs. So this doesn't look like it has been there since 2007. I'll try to debug it when I get a chance. 

-- 
Sent from a small device: formatting sux and brevity is inevitable.

Re: [PATCH] boot install: Partially refactor the logic for detecting bootloader

[Beru Shinsetsu]

On Thu, 2022-03-17 at 13:42 +0000, Boris Petkov wrote:
> On March 17, 2022 1:16:26 PM UTC, Beru Shinsetsu
> <windowz414@gnuweeb.org> wrote:
> > I guess I had pure luck having this patch seen? xd
> 
> I'm not sure what you mean here??

Eeee it was just a flash of thought, nothing important. ^^;

> > To be honest with you, nothing has changed _just recently_ to cause
> > this error message to come up.
> 
> Well, I saw this on SLE15-SP4 (brand new) yesterday while I haven't
> seen it on previous service packs. So this doesn't look like it has
> been there since 2007. I'll try to debug it when I get a chance.

Hmm alright. Good luck from now! Hope everything goes flawlessly.
-- 
Beru Shinsetsu

Re: [PATCH] boot install: Partially refactor the logic for detecting bootloader

[Borislav Petkov]

On Thu, Mar 17, 2022 at 04:46:48PM +0300, Beru Shinsetsu wrote:
> > Well, I saw this on SLE15-SP4 (brand new) yesterday while I haven't
> > seen it on previous service packs. So this doesn't look like it has
> > been there since 2007. I'll try to debug it when I get a chance.
> 
> Hmm alright. Good luck from now! Hope everything goes flawlessly.

Here it is:

From arch/x86/boot/install.sh:

...
# User may have a custom install script

if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi
...

so distros *usually* should supply a custom, distro-specific
installkernel script which does that. The distros which you are seeing
it on simply don't have that script installed and I need to talk to
distro people as to what the rule there is for supplying such a script
now.

Because most distros should supply it though and those new distros
dropping it looks like some new "strategy" or so.

We'll see.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] boot install: Partially refactor the logic for detecting bootloader

[Beru Shinsetsu]

On Sat, 2022-03-19 at 22:20 +0100, Borislav Petkov wrote:
> On Thu, Mar 17, 2022 at 04:46:48PM +0300, Beru Shinsetsu wrote:
> > > Well, I saw this on SLE15-SP4 (brand new) yesterday while I haven't
> > > seen it on previous service packs. So this doesn't look like it has
> > > been there since 2007. I'll try to debug it when I get a chance.
> > 
> > Hmm alright. Good luck from now! Hope everything goes flawlessly.
> 
> Here it is:
> 
> From arch/x86/boot/install.sh:
> 
> ...
> # User may have a custom install script
> 
> if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
> if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi
> ...
> 
> so distros *usually* should supply a custom, distro-specific
> installkernel script which does that. The distros which you are seeing
> it on simply don't have that script installed and I need to talk to
> distro people as to what the rule there is for supplying such a script
> now.
> 
> Because most distros should supply it though and those new distros
> dropping it looks like some new "strategy" or so.
> 
> We'll see.

I have seen that, and I had pretty much the same thoughts as well. Arch
isn't quite new either. And as I said, installing from AUR works pretty
fine (package is `linux-mainline`, it also compiles the kernel on
*your* PC locally, then installs it as a PacMan package). Just
compiling manually doesn't. I suppose that's one of the quirks of the
distro being installed manually by the user from the very first stage.
Not even counting Gentoo though, I haven't tried it out as I'm scared
it can explode my laptop as it *compiles the whole system locally*. But
let's see how it goes. Thank you so much by the way!
-- 
Beru Shinsetsu