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
