GNU bug report logs - #26339
[PATCH 00/18] wip: Support non grub bootloaders.

Previous Next

Package: guix-patches;

Reported by: Mathieu Othacehe <m.othacehe <at> gmail.com>

Date: Sun, 2 Apr 2017 13:51:01 UTC

Severity: important

Tags: patch

Done: Mathieu Othacehe <m.othacehe <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Mathieu Othacehe <m.othacehe <at> gmail.com>
Cc: 26339 <at> debbugs.gnu.org, Ludovic Courtès <ludo <at> gnu.org>
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 <m.othacehe <at> gmail.com> 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 configuration).

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 :

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26339#504 (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 http://www.syslinux.org/wiki/index.php?title=Mbr 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).

WDYT?

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26339#507 (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.

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26339#519 (allow user to
> specifiy bootloader-configuration without package nor installer).

LGTM!

[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:
    - https://community.nxp.com/thread/436638
    - https://devtalk.nvidia.com/default/topic/802953/jetson-tk1/how-to-compile-amp-install-mainline-u-boot-/
    - https://eewiki.net/display/linuxonarm/i.MX6x+SABRE+Lite+Mainline+U-Boot
    - https://github.com/xobs/u-boot-novena
    - https://archlinuxarm.org/forum/viewtopic.php?f=53&t=7290
    - https://forum.mqmaker.com/t/mainline-u-boot/673/2
    - http://elinux.org/RPi_U-Boot#Mainline
    - https://blogs.s-osg.org/use-mainline-u-boot-non-signed-kernels-exynos-chromebooks/
    - https://forum.odroid.com/viewtopic.php?t=25207




This bug report was last modified 7 years and 209 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.