|
(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 look at the grub config in an official Wheezy disc (beware that in EFI it displays in a larger resolution than in BIOS mode though). 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. See above; I'm all for themeing grub2 to look more like syslinux. However, I still don't get it with the background, unless it's the text in the default syslinux svg splash you're interested in having in grub2, because otherwise they are already the same... 3) Syslinux and grub hybrid iso ... I'm not really following here. I am actually relatively new to Linux and some of the areas I am dealing with in the live-build code. I need to reread what you said here, perhaps do a little research and get back to you after I've completed some other bits of work. I think what you are describing is what's currently done with bootloaders directory, at least, for the isolinux family. You can check: http://live.debian.net/manual/stable/html/live-manual.en.html#563 to see what I mean. It's not perfect (it does not have heritage) but it usually works. Yes, I'm aware of that, but the lack of "heritage" as you put it forces derivatives (and even Debian's live-images package) to duplicate files that are not being changed from the defaults, making the burden of maintaining those copies greater (needing to watch out for and merge changes across a greater number of files), for instance, so I want to investigate improving things here. In fact I'm not totally thrilled by the duplication of files across the syslinux family of bootloader directories. I wanted myself to improve it so that grub2 does the same thing as I have explained before. As far as I know bootloaders/grub2/ folder is not checked by binary_grub2. Actually that functionality is already there for grub/grub2, it's just a different directory, because the grub/grub2 files are for whatever reason considered "template" files rather than "bootloader" files, so it's config/templates/grub2 not config/bootloaders/grub2, unlike with syslinux. Note (in live-build v4.x/5.x at least) the 'Check_templates grub2' function execution in the binary_grub2 script, and the Check_templates function in functions/templates.sh, this looks for a local config template directory and sets the location in the TEMPLATE variable, which is used later in binary_grub2. I don't really see the point in grub/grub2 stuff being treated differently in this way though... |