[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26339: "extlinux", "extlinux" gpt, bootloader-configuration without

From: Danny Milosavljevic
Subject: bug#26339: "extlinux", "extlinux" gpt, bootloader-configuration without package nor installer
Date: Sun, 11 Jun 2017 11:54:57 +0200

Hi Mathieu,

On Sun, 11 Jun 2017 10:42:15 +0200
Mathieu Othacehe <address@hidden> wrote:

>Ok then, would the following bootloader be ok ?
>(define extlinux-bootloader-no-installer
>  (bootloader
>   (inherit extlinux-bootloader)
>   (installer #f)))

Uhh I guess so.  Weird to have the hierarchy like that, though.

Much less strange would be to have a hierarchy like this:
- extlinux-bootloader ; really means extlinux-configuration-style bootloader
  - syslinux-bootloader
  - u-boot-bootloader

Using extlinux-bootloader directly as a user doesn't make a lot of sense - but 
if they do it, it shouldn't install any bootloader (only extlinux 

If you used syslinux-bootloader, it would do the same as extlinux-bootloader 
and also install syslinux (mbr.bin, gptmbr.bin).

If you used u-boot-bootloader, it would do the same as extlinux-bootloader and, 
if you provided an u-boot package to use, also install u-boot (eventually.  The 
latter is not easy and usually a bad idea except for a select few boards [1]).

> Just to review the situation on the bootloader serie, there are still 3
> patches, that may have gone unnoticed in #26339, here are the links :

> (add extlinux
> gpt support).

Not sure why this goes into extlinux.  Extlinux is just a configuration 
standard.  It wouldn't have those installation files "mbr.bin", "gptmbr.bin".

According to it seems these 
are part of the syslinux bootloader distribution.

It was weird like that before patch 504 but I don't think it makes sense to 
conflate extlinux with syslinux.

If you do it like that, that means when you use U-Boot (which also uses 
extlinux config file), extlinux-* will install useless files "mbr.bin" and 
"gptmbr.bin".  Where would it get those in the first place?  Does it install 
syslinux too, then?  Apparently.  So now the user machine has two bootloaders, 
syslinux *and* u-boot ?  I hope it doesn't clobber u-boot in that case.

Really, I think the inheritance should go like this:

- extlinux-bootloader ; really means extlinux-configuration-style bootloader
  - syslinux-bootloader
  - u-boot-bootloader
  - maybe ipxe-bootloader

And I think u-boot-bootloader, when it eventually exists, should not install 
the u-boot bootloader by default either (i.e. it shouldn't default to a 
specific u-boot package).


> (add extlinux
> gpt test).

Here, it correctly says syslinux-os.

LGTM!  I think complicating the tests by refactoring %minimal-os is not 
necessary - so it's OK as is.

> (allow user to
> specifiy bootloader-configuration without package nor installer).


[1] There are a lot of forks of u-boot.  Vendors usually build and install 
their strange [usually old] u-boot fork on the device.
    Often, mainline u-boot eventually works after some time (i.e. after it was 
merged upstream), but I wouldn't bet on it.
    So one should load the new bootloader temporarily (by loading it via a 
RAMload stage like FEL over USB or my using a throwaway SD card or by using a 
test clip).  Otherwise, if u-boot ever didn't work you couldn't recover without 
extra external hardware and a lot of pain.  There's no "BIOS setup" where you 
can revert to a previous version of u-boot or anything.  But if it's only 
"installed" in RAM, you can just reboot if it doesn't work - it will be gone.
    Also, for comparison, if one "just" broke the Linux kernel installation or 
the extlinux bootmenu file, u-boot has a console with keyboard, display and 
serial port support and can boot Linux from TFTP and from other files on SD 
cards and flash.  So that wouldn't be that bad.
    To get an overview:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]