Bug#775322: Bootloader code issues and improvements
El 18/01/15 a las 07:27, jnqnfe escribió: (forgot to cc the bug, here's a copy) I did not find that problem in my tests. But that can be explained by saying that my initial tests were done with live-build-4.0. The problem also exists in 4.x. For my text amd64 sid build using grub2, I have the following grub2 menu entries: - Debian GNU/Linux - live - Debian GNU/Linux - live (fail-safe mode) - Debian GNU/Linux - live, kernel 3.16.0-4-amd64 - Debian GNU/Linux - live, kernel 3.16.0-4amd64 (fail-safe mode) - installer entries If you ignore the labels and look at the kernel, initrd and append (kernel param) details behind them (by looking at the grub config file, or using edit mode when grub is running), you'll see that the 1st entry is identical to the 3rd and the 2nd is identical to the 4th. (In actual fact all four will be identical building from the current 4.x/5.x codebases due to a mistake in the code, which I have fixed in the set of patches provided earlier). The current code always outputs the first two default entries (if you specify multiple kernel flavours then it uses the first specified here), then it outputs a pair for each and every kernel flavour specified, even though that creates duplicate entries for the first. This is not the case in syslinux. I intend to rework grub2 to remove this redundancy, matching syslinux. Now I understand what you mean. Thank you. As I was about to improve grub2 support on Live Build (changed my mind because Debian's Grub2 package does not match the minimum for Super Grub2 Disk) I'll explain a bit about what I had in mind. Hopefully you can share some of these ideas and, who knows, implement some of them. 1) SVG and bootloaders directory 1.1) If you check the current default Debian Live, at least in Debian Wheezy, you will see that its boot background image for syslinux/isolinux family is based on a: svg.in file which gets converted into a svg. Finally the svg file is converted into something that svg can understand. I had no idea what you were talking about, then I went and took a brief look at the live-build v3.x code and I see it. I haven't used 3.x, and I haven't looked in any detail at the code you're referring to, but 4.x changed this behaviour; it replaces a few text placeholders in the svg it uses, but then just uses that svg, it does not convert it to a png. That is, with a config that defaults to using the /usr/share/live/build/bootloaders files, and thus the splash with the black background and yellow construction workers helmet, which contains those placeholders. If using a config from the live-images package, these contain a local config copy of the bootloader files, with a different, Debian themed svg, without the text placeholders, so the svg is used as is. This is from debian-old-4.0: http://live.debian.net/gitweb/?p=live-build.git;a=blob;f=scripts/build/binary_syslinux;h=568b3f75729cf309d29524156b65cde28b1bb17e;hb=refs/heads/debian-old-4.0#l345 where you can see that svg gets converted into a png. And this is from debian-next: http://live.debian.net/gitweb/?p=live-build.git;a=blob;f=scripts/build/binary_syslinux;h=5c9ce04bb89652e9dbfe0349ecd2af65c982da08;hb=refs/heads/debian-next#l295 Syslinux or isolinux is not using SVG directly but a png. Take a look here too: http://live.debian.net/gitweb/?p=live-build.git;a=blob;f=share/bootloaders/syslinux/stdmenu.cfg;h=671b16f786ffcdf61e6629b88d763591cf8d2bfe;hb=refs/heads/debian-next#l1 I'm just saying to clone and reuse this code but to produce an image that grub2 can understand and use in one of its themes. For grub2, the template files in /usr/share/live/build/templates/grub2 are used, including a tga splash image which is identical to the default syslinux one, except being a tga, the text placeholder thing can't be done. So unless you really want that text, the splash is otherwise the same, and I see no point in generating a tga/png from the svg. Well, I want the image to be exactly the same, so yes, there's a point to me. On the issue of the text displayed in the svg, I actually really dislike it. I was considering the possibility of alternate solutions for providing that info in the bootloader. I haven't explored that much yet though since I've got much more important things to work on. Yes, I might agree on the default text not being the best one. But I like the idea, as a derivative distro, to be able to edit the svg.in file (even if you say that now it's svg without the .in) and add some variables or text of my own. 1.2) Rework the theme to match the default syslinux one. Rework the current grub2 theme (if there is one) to match the current syslinux one. Why? I would like to see the same boot menu by default either by using syslinux as a bootloaer or by using grub2. I am not completely sure what you're talking about here, there are three possibilities that come to mind (perhaps you mean more than one of these): 1) Menu label consistency between
Bug#775322: Bootloader code issues and improvements
(forgot to cc the bug, here's a copy) I did not find that problem in my tests. But that can be explained by saying that my initial tests were done with live-build-4.0. The problem also exists in 4.x. For my text amd64 sid build using grub2, I have the following grub2 menu entries: - Debian GNU/Linux - live - Debian GNU/Linux - live (fail-safe mode) - Debian GNU/Linux - live, kernel 3.16.0-4-amd64 - Debian GNU/Linux - live, kernel 3.16.0-4amd64 (fail-safe mode) - installer entries If you ignore the labels and look at the kernel, initrd and append (kernel param) details behind them (by looking at the grub config file, or using edit mode when grub is running), you'll see that the 1st entry is identical to the 3rd and the 2nd is identical to the 4th. (In actual fact all four will be identical building from the current 4.x/5.x codebases due to a mistake in the code, which I have fixed in the set of patches provided earlier). The current code always outputs the first two default entries (if you specify multiple kernel flavours then it uses the first specified here), then it outputs a pair for each and every kernel flavour specified, even though that creates duplicate entries for the first. This is not the case in syslinux. I intend to rework grub2 to remove this redundancy, matching syslinux. As I was about to improve grub2 support on Live Build (changed my mind because Debian's Grub2 package does not match the minimum for Super Grub2 Disk) I'll explain a bit about what I had in mind. Hopefully you can share some of these ideas and, who knows, implement some of them. 1) SVG and bootloaders directory 1.1) If you check the current default Debian Live, at least in Debian Wheezy, you will see that its boot background image for syslinux/isolinux family is based on a: svg.in file which gets converted into a svg. Finally the svg file is converted into something that svg can understand. I had no idea what you were talking about, then I went and took a brief look at the live-build v3.x code and I see it. I haven't used 3.x, and I haven't looked in any detail at the code you're referring to, but 4.x changed this behaviour; it replaces a few text placeholders in the svg it uses, but then just uses that svg, it does not convert it to a png. That is, with a config that defaults to using the /usr/share/live/build/bootloaders files, and thus the splash with the black background and yellow construction workers helmet, which contains those placeholders. If using a config from the live-images package, these contain a local config copy of the bootloader files, with a different, Debian themed svg, without the text placeholders, so the svg is used as is. I'm just saying to clone and reuse this code but to produce an image that grub2 can understand and use in one of its themes. For grub2, the template files in /usr/share/live/build/templates/grub2 are used, including a tga splash image which is identical to the default syslinux one, except being a tga, the text placeholder thing can't be done. So unless you really want that text, the splash is otherwise the same, and I see no point in generating a tga/png from the svg. On the issue of the text displayed in the svg, I actually really dislike it. I was considering the possibility of alternate solutions for providing that info in the bootloader. I haven't explored that much yet though since I've got much more important things to work on. 1.2) Rework the theme to match the default syslinux one. Rework the current grub2 theme (if there is one) to match the current syslinux one. Why? I would like to see the same boot menu by default either by using syslinux as a bootloaer or by using grub2. I am not completely sure what you're talking about here, there are three possibilities that come to mind (perhaps you mean more than one of these): 1) Menu label consistency between grub2 and syslinux, and menu hierarchy. I would like to see consistency here and that's something I'm working towards in these patches. 2) Splash theme consistency. The splash, with the exception of the text mentioned above, is already identical. 3) Trying to manipulate grub2 into displaying things similarly to syslinux, e.g. changing the size and location of the menu box, etc. I have no idea whether this can be done, though I have noticed that the EFI grub2 bootloader menu displayed from an official Debian Wheezy install disc looks completely different to how I expect grub menus to look. Perhaps you can theme things much more than I realise (more than just splash and a few text/background/highlight colours). If we can, and a brief google image search suggests it may very well be possible, then I am totally on board with doing that, and by all means go ahead and get started on this if you like; I would suggest you start by taking the new Jessie svg splash I supplied in bug #775527, make a png from that, use live-build v5.x from debian next, plus my supplied set of patches, and take a
Bug#775322: Bootloader code issues and improvements
El 17/01/15 a las 02:21, jnqnfe escribió: On 15/01/2015 14:52, adrian15 wrote: I just write down here that I will have to review your mentioned: #1, #2, #3, #4, #5, #6, #7, #8 and #9 in my (#757883) (support for loopback.cfg file) so that it matches your improvements and fixes. No problem, I will upload the first batch of work soon, just running a test and need to find out why I'm getting an error trying to load memtest86 first. I will also take your looback support into consideration and try to help review it and mold it into a state ready to merge. Thank you very much! Do you mean the normal entry and the single entry per one kernel? Or do you actually mean repeated kernels? Syslinux generates only a single pair (normal + failsafe) when there is only one kernel, and if multiple kernels, one such pair each. With grub/grub2, it's outputting this pair of entries as a standard/default pair, then also one per kernel, so for one of the kernels you're getting double entries, i.e. if you've only got only one kernel, you get two normal entries and two failsafe entries that are identical except in their labels, which is unecessary. I intend to bring grub2 inline with syslinux. I did not find that problem in my tests. But that can be explained by saying that my initial tests were done with live-build-4.0. I had also thought on this problem. I think there should a way of just reusing the current syslinux SVG file so that it generates a suitable image that can be used by grub2 as a background image. I disagree, why add such complexity to live-build when you can just provide a ready made image file as we do now. Besides, this problem wasn't about creation of the image, it was about grub2 not displaying it. I have created a small set of commits which improve the grub2 config file, solving several graphics configuration issues, including a getting the splash background displayed. As I was about to improve grub2 support on Live Build (changed my mind because Debian's Grub2 package does not match the minimum for Super Grub2 Disk) I'll explain a bit about what I had in mind. Hopefully you can share some of these ideas and, who knows, implement some of them. 1) SVG and bootloaders directory 1.1) If you check the current default Debian Live, at least in Debian Wheezy, you will see that its boot background image for syslinux/isolinux family is based on a: svg.in file which gets converted into a svg. Finally the svg file is converted into something that svg can understand. I'm just saying to clone and reuse this code but to produce an image that grub2 can understand and use in one of its themes. 1.2) Rework the theme to match the default syslinux one. Rework the current grub2 theme (if there is one) to match the current syslinux one. Why? I would like to see the same boot menu by default either by using syslinux as a bootloaer or by using grub2. You will understand why a bit later. 2) Syslinux and loopback If you check my bug about loopback cfg support you will see that I'm using as much as I can the default grub2 code. Let's suppose you build a Debian Live which has loopack cfg support. If you boot it normally isolinux will show the default syslinux theme and it will be pretty. If you boot it from Super Grub2 Disk thanks to its option to load loopback cfg you will find another no-so-pretty menu. If the loopback cfg support code in Live Build takes that into consideration it will take the syslinux svg.in, convert it into svg, then into a grub2-theme-suitable-image. Then you can have a great menu even if booting from Super Grub2 Disk or other loopback cfg system. 3) Syslinux and grub hybrid iso My grub2 improvements suggestions are given by me wanting Super Grub2 Disk to be included by default on Debian Live builds. The thing is that I do not want it to be emulated as a RAM image but I want it to be native. That would also add the benefit of supporting EFI by default very easily. So, first of all I need a grub2 based Debian Live which its grub2 package matches minimum requirements for Super Grub2 Disk (not in Jessie currently). Then I just need to make the Super Grub2 Disk scripts (they are just cfg files) get into that disk. So what does happen when you have a grub2 Debian Live iso? How do the multi distro usb tools handle them? Well, most of these tools cannot handle them. However these tools are very good at handling isolinux based isos. So... a nice new option for Debian Live which I think I would only use myself for Rescatux would be the following one: Build a grub2 based Debian Live while at the same time you add to it the files that isolinux build would have added. Just to be clear in the end the ISO would be booted by grub2 but not by isolinux. This new kind of syslinux and grub hybrid iso will have the advantage of having a native grub2 (thus a native Super Grub2 Disk would be easy) and at the same time the Multi USB tools will detect it as
Bug#775322: Bootloader code issues and improvements
Additional issue: #23) d syslinux does not apply kernel version filtering to multi-flavour scenarios -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775322: Bootloader code issues and improvements
Additional issue: #23) syslinux does not apply kernel version filtering to multi-flavour scenarios -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775322: Bootloader code issues and improvements
Additional issue: #21) syslinux looks in wrong location (binary/live instead of binary/boot) when LB_INITRAMFS is not live-boot or casper. Same issue as #20, but affecting syslinux here and resulting from a related mistake with a different case structure and variable, which is out of line with other scripts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775322: Bootloader code issues and improvements
On 15/01/2015 14:52, adrian15 wrote: I just write down here that I will have to review your mentioned: #1, #2, #3, #4, #5, #6, #7, #8 and #9 in my (#757883) (support for loopback.cfg file) so that it matches your improvements and fixes. No problem, I will upload the first batch of work soon, just running a test and need to find out why I'm getting an error trying to load memtest86 first. I will also take your looback support into consideration and try to help review it and mold it into a state ready to merge. Do you mean the normal entry and the single entry per one kernel? Or do you actually mean repeated kernels? Syslinux generates only a single pair (normal + failsafe) when there is only one kernel, and if multiple kernels, one such pair each. With grub/grub2, it's outputting this pair of entries as a standard/default pair, then also one per kernel, so for one of the kernels you're getting double entries, i.e. if you've only got only one kernel, you get two normal entries and two failsafe entries that are identical except in their labels, which is unecessary. I intend to bring grub2 inline with syslinux. I had also thought on this problem. I think there should a way of just reusing the current syslinux SVG file so that it generates a suitable image that can be used by grub2 as a background image. I disagree, why add such complexity to live-build when you can just provide a ready made image file as we do now. Besides, this problem wasn't about creation of the image, it was about grub2 not displaying it. I have created a small set of commits which improve the grub2 config file, solving several graphics configuration issues, including a getting the splash background displayed. If it's grub1 I don't think it's worth maintaining it. But, I don't know what's the Debian's grub vs grub2 policy in Jessie actually. Agreed. I made an attempt to fix this, but failed and posted a request for help in the Debian boot mailing list. This led to a very brief discussion with Steve McIntyre who feels the same. I just need maintainer's support and I'll add a commit into the set I'm providing here to rip grub-legacy out of live-build. Please check (#757883) (support for loopback.cfg file) where you can see how I re-use syslinux code to avoid syslinux being stubborn on renaming the kernel filenames. Don't get me wrong, I also prefer the kernel files to be renamed always so that the code is consistent accross all the bootloaders. Will do. My dream is defining these variables or settings once (in a xml file? in a ini file?) and then being translated into a syslinux file or to a grub2 file. Same feeling here. Perhaps this could be achieved in the planned python rewrite/transition. Also to be considered, particularly in respect to #18 and #19 are bug #757697 (support arch autodetection) and the best way to allow derivatives (e.g. Kali) to replace menu components such as labels and splash. Yes, I also think that somehow a DerivativeName setting is missing so that we can easily replace Debian to e.g. Kali from a config file without too much effort. Kali is doing more than just using a different title; some of their changes, e.g. adding an install with speech synthesizer option for accessibility purposes, are covered in the work I am doing here, but they also make other changes like adding new usb persistence menu entries. I think, rather than adding to live-build to provide the capability of outputting such extra menus for derivatives needing it, I want to explore how best we can provide a means for such distributions to provide alternate config templates, in which placeholders are filled in by live-build. I am thinking along the lines of live-build providing a default set of files, then derivatives like Kali providing a modified copy of only the files they change (splash background being the most obvious); so live-build takes a copy of the default set, copies over that the derivative specific set (provided in the user's config perhaps), then replaces the placeholders in this set with any details that need writing to them. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775322: Bootloader code issues and improvements
Additional issue: #22) broken path preventing use of memtest86(+) from grub2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775322: Bootloader code issues and improvements
Ok, here is the first set of patches. Attached is an archive with a set of commits that cover issues #1-8, 10-11, 13-16, and 20-22. These have been built on top of the debian-next (5.x) branch. #17 is being ignored, I'm not going to spend any further time on grub-legacy, and hopefully if Daniel (maintainer) agrees, we can rip out support for it in a further commit. So that leaves #9, 12, 18 and 19. For #9 I need to know exactly what new alternative kernel parameters to switch to. I did try playing with it a little, but didn't have any success - tests resulted in a black screen after selecting the bootloader menu item. Anyone want to help on this? I will get to work on the rest shortly. 775322.tar.gz Description: GNU Zip compressed data
Bug#775322: Bootloader code issues and improvements
Additional issue: #23) The syslinux/menu.cfg file has a caret character at the beginning of the Advanced options title; this character can be used to create hotkeys with labels, but does not work with titles and so should not be there. This lead me to incorrectly add this caret to three other files in commit-13 and introduce the use of it in further titles in commit-14. The attached additional commit (commit-26) corrects this. I'll see if it is possible to add labels as well as titles for submenu entries later (hotkeys might help people with accessibility needs navigate the new menu structure to 'installer options' 'install with speech synthesis' easier (pressing 'i' then 's')). commit 484ee5c6f90341ad84b2f111e5c5e9b72dbb118d Author: jnqnfe jnq...@gmail.com Date: Sat Jan 17 06:36:49 2015 + Remove caret character from menu titles in syslinux diff --git a/share/bootloaders/extlinux/install.cfg b/share/bootloaders/extlinux/install.cfg index 12b7808..88c5ef6 100644 --- a/share/bootloaders/extlinux/install.cfg +++ b/share/bootloaders/extlinux/install.cfg @@ -1,5 +1,5 @@ menu begin install - menu title ^Install options + menu title Install options include stdmenu.cfg label mainmenu menu label ^Back.. diff --git a/share/bootloaders/extlinux/menu.cfg b/share/bootloaders/extlinux/menu.cfg index 0bbbfcc..bb492b6 100644 --- a/share/bootloaders/extlinux/menu.cfg +++ b/share/bootloaders/extlinux/menu.cfg @@ -6,7 +6,7 @@ include stdmenu.cfg include live.cfg @OPTIONAL_INSTALLER_INCLUDE@ menu begin advanced - menu title ^Advanced options + menu title Advanced options include stdmenu.cfg label mainmenu menu label ^Back.. diff --git a/share/bootloaders/isolinux/install.cfg b/share/bootloaders/isolinux/install.cfg index 12b7808..88c5ef6 100644 --- a/share/bootloaders/isolinux/install.cfg +++ b/share/bootloaders/isolinux/install.cfg @@ -1,5 +1,5 @@ menu begin install - menu title ^Install options + menu title Install options include stdmenu.cfg label mainmenu menu label ^Back.. diff --git a/share/bootloaders/isolinux/menu.cfg b/share/bootloaders/isolinux/menu.cfg index 0bbbfcc..bb492b6 100644 --- a/share/bootloaders/isolinux/menu.cfg +++ b/share/bootloaders/isolinux/menu.cfg @@ -6,7 +6,7 @@ include stdmenu.cfg include live.cfg @OPTIONAL_INSTALLER_INCLUDE@ menu begin advanced - menu title ^Advanced options + menu title Advanced options include stdmenu.cfg label mainmenu menu label ^Back.. diff --git a/share/bootloaders/pxelinux/install.cfg b/share/bootloaders/pxelinux/install.cfg index 12b7808..88c5ef6 100644 --- a/share/bootloaders/pxelinux/install.cfg +++ b/share/bootloaders/pxelinux/install.cfg @@ -1,5 +1,5 @@ menu begin install - menu title ^Install options + menu title Install options include stdmenu.cfg label mainmenu menu label ^Back.. diff --git a/share/bootloaders/pxelinux/menu.cfg b/share/bootloaders/pxelinux/menu.cfg index 0bbbfcc..bb492b6 100644 --- a/share/bootloaders/pxelinux/menu.cfg +++ b/share/bootloaders/pxelinux/menu.cfg @@ -6,7 +6,7 @@ include stdmenu.cfg include live.cfg @OPTIONAL_INSTALLER_INCLUDE@ menu begin advanced - menu title ^Advanced options + menu title Advanced options include stdmenu.cfg label mainmenu menu label ^Back.. diff --git a/share/bootloaders/syslinux/install.cfg b/share/bootloaders/syslinux/install.cfg index 12b7808..88c5ef6 100644 --- a/share/bootloaders/syslinux/install.cfg +++ b/share/bootloaders/syslinux/install.cfg @@ -1,5 +1,5 @@ menu begin install - menu title ^Install options + menu title Install options include stdmenu.cfg label mainmenu menu label ^Back.. diff --git a/share/bootloaders/syslinux/menu.cfg b/share/bootloaders/syslinux/menu.cfg index 0bbbfcc..bb492b6 100644 --- a/share/bootloaders/syslinux/menu.cfg +++ b/share/bootloaders/syslinux/menu.cfg @@ -6,7 +6,7 @@ include stdmenu.cfg include live.cfg @OPTIONAL_INSTALLER_INCLUDE@ menu begin advanced - menu title ^Advanced options + menu title Advanced options include stdmenu.cfg label mainmenu menu label ^Back..
Bug#775322: Bootloader code issues and improvements
El 14/01/15 a las 04:54, jnqnfe escribió: Package: live-build Version: 5.0~a2-1 Reviewing the bootloader menu creation code, I have drawn up the following list of fixes and improvements needed. Some of these I have already reported and supplied patches for separately, but I'm listing them here again to provide a comprehensive set of issues. Where applicable, I'll specify the bug number of the separate bug report either specifically for the issue, or where a patch has been previously supplied already as part of addressing something else. I intend to wrap this bug report up with one or more sets of commits to address them all. Thank you for your recent hard work. Broken boot capability issues: --- #1) grub2 broken, with missing file error on boot due to files being placed in the wrong directory (#775316). Kernel parameter issues: --- #2) [install entries] user supplied kernel params added in wrong position in grub/grub2 (#775143). #3) [install entries] 'quiet' (d-i?) param excluded from rescue entries instead of expert entries in grub2 (#775143). #4) [install entries] the '--' delimiter prior to the (d-i?) quiet kernel parameter is not output for grub/grub2 (#775143). #5) [install entries] the '--' delimiter needs to be replaced now with '---' (#775128). #6) [live entries] user supplied kernel params added in wrong position in grub/grub2 (less important than for installer entries) (#775143). #7) [live entries] normal user supplied params being added to fail-safe entry instead of fail-safe user params in grub/grub2. #8) [live entries] unnecessary replacement of fail-safe-installer user params placeholder in syslinux #9) depreciated video/graphics kernel parameters are being used. Menu entry set issues: --- #10) [install entries] speech synthesis option missing, affecting accessibility I just write down here that I will have to review your mentioned: #1, #2, #3, #4, #5, #6, #7, #8 and #9 in my (#757883) (support for loopback.cfg file) so that it matches your improvements and fixes. Unless somehow your #18 is fixed so that the kernel is always renamed. That would probably mean that I could just do as the grml implementation [1] which would be as simple as always generating grub2 file and symlinking /boot/grub/loopback.cfg to /boot/grub/grub.cfg . #12) [live entries] too many entries added in grub/grub2 (redundant entries with kernel version specified) Do you mean the normal entry and the single entry per one kernel? Or do you actually mean repeated kernels? #13) memtest entry included in syslinux menus even if no memtest included #14) install entries included in syslinux menus even if no installer included What I had found out myself is that there were installer entries in grub2 but not in syslinux but that was when I checked it in Wheezy's Debian Live so that might explain it. In GIT it should be as you explain then. Other issues: --- #16) grub2 splash not being displayed I had also thought on this problem. I think there should a way of just reusing the current syslinux SVG file so that it generates a suitable image that can be used by grub2 as a background image. #17) grub splash displayed, but horribly (can this be fixed?) If it's grub1 I don't think it's worth maintaining it. But, I don't know what's the Debian's grub vs grub2 policy in Jessie actually. #18) grub/grub2 do not rename kernel files unlike syslinux. syslinux does this for a technical reason, but it might be desirable to do across the board anyway. This needs further consideration. Please check (#757883) (support for loopback.cfg file) where you can see how I re-use syslinux code to avoid syslinux being stubborn on renaming the kernel filenames. Don't get me wrong, I also prefer the kernel files to be renamed always so that the code is consistent accross all the bootloaders. #19) consider switching grub/grub2 code to work more like syslinux, with pre-constructed pieces of the menus in files, from which the full menu can be constructed by including chunks from those files, and replacing placeholders. Well, yes, we could do that with grub2 variables. My dream is defining these variables or settings once (in a xml file? in a ini file?) and then being translated into a syslinux file or to a grub2 file. Also to be considered, particularly in respect to #18 and #19 are bug #757697 (support arch autodetection) and the best way to allow derivatives (e.g. Kali) to replace menu components such as labels and splash. Yes, I also think that somehow a DerivativeName setting is missing so that we can easily replace Debian to e.g. Kali from a config file without too much effort. As of this moment I have written patches for 11 of these issues, some of which have already been posted separately. More to follow soon. Thank you again for your hard work. adrian15 [1]:
Bug#775322: Bootloader code issues and improvements
Additional issue: #20) grub2 looks in wrong location (binary/live instead of binary/boot) when LB_INITRAMFS is not live-boot or casper. I have built patches for 14/20 issues now, will upload soon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775322: Bootloader code issues and improvements
Package: live-build Version: 5.0~a2-1 Reviewing the bootloader menu creation code, I have drawn up the following list of fixes and improvements needed. Some of these I have already reported and supplied patches for separately, but I'm listing them here again to provide a comprehensive set of issues. Where applicable, I'll specify the bug number of the separate bug report either specifically for the issue, or where a patch has been previously supplied already as part of addressing something else. I intend to wrap this bug report up with one or more sets of commits to address them all. Broken boot capability issues: --- #1) grub2 broken, with missing file error on boot due to files being placed in the wrong directory (#775316). Kernel parameter issues: --- #2) [install entries] user supplied kernel params added in wrong position in grub/grub2 (#775143). #3) [install entries] 'quiet' (d-i?) param excluded from rescue entries instead of expert entries in grub2 (#775143). #4) [install entries] the '--' delimiter prior to the (d-i?) quiet kernel parameter is not output for grub/grub2 (#775143). #5) [install entries] the '--' delimiter needs to be replaced now with '---' (#775128). #6) [live entries] user supplied kernel params added in wrong position in grub/grub2 (less important than for installer entries) (#775143). #7) [live entries] normal user supplied params being added to fail-safe entry instead of fail-safe user params in grub/grub2. #8) [live entries] unnecessary replacement of fail-safe-installer user params placeholder in syslinux #9) depreciated video/graphics kernel parameters are being used. Menu entry set issues: --- #10) [install entries] speech synthesis option missing, affecting accessibility #11) [install entries] lots of install options not provided by syslinux menus #12) [live entries] too many entries added in grub/grub2 (redundant entries with kernel version specified) #13) memtest entry included in syslinux menus even if no memtest included #14) install entries included in syslinux menus even if no installer included Other issues: --- #15) [live entries] undocumented user failsafe params option #16) grub2 splash not being displayed #17) grub splash displayed, but horribly (can this be fixed?) #18) grub/grub2 do not rename kernel files unlike syslinux. syslinux does this for a technical reason, but it might be desirable to do across the board anyway. This needs further consideration. #19) consider switching grub/grub2 code to work more like syslinux, with pre-constructed pieces of the menus in files, from which the full menu can be constructed by including chunks from those files, and replacing placeholders. Also to be considered, particularly in respect to #18 and #19 are bug #757697 (support arch autodetection) and the best way to allow derivatives (e.g. Kali) to replace menu components such as labels and splash. As of this moment I have written patches for 11 of these issues, some of which have already been posted separately. More to follow soon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
