From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJzbJ-0000Qc-Cs for guix-patches@gnu.org; Sun, 11 Jun 2017 05:56:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dJzbG-00049m-Ac for guix-patches@gnu.org; Sun, 11 Jun 2017 05:56:05 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:37090) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dJzbG-00049g-6Y for guix-patches@gnu.org; Sun, 11 Jun 2017 05:56:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dJzbF-0007G0-Pl for guix-patches@gnu.org; Sun, 11 Jun 2017 05:56:01 -0400 Subject: bug#26339: "extlinux", "extlinux" gpt, bootloader-configuration without package nor installer Resent-Message-ID: Date: Sun, 11 Jun 2017 11:54:57 +0200 From: Danny Milosavljevic Message-ID: <20170611115457.72395d51@scratchpost.org> In-Reply-To: <8760g2oqzc.fsf@gmail.com> References: <20170402134916.2871-1-m.othacehe@gmail.com> <20170610085327.1353-1-m.othacehe@gmail.com> <87lgozyl52.fsf@gnu.org> <8760g2oqzc.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Mathieu Othacehe Cc: 26339@debbugs.gnu.org Hi Mathieu, On Sun, 11 Jun 2017 10:42:15 +0200 Mathieu Othacehe 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