On Thu, 04 Jul, at 08:45:33AM, Andreas Heinlein wrote:> Looks like you're right. I added '*.tr *.hlp *.pcx back.jpg > gfxboot.cfg langlist' to the 'bootlogo' archive, and now I get the > menu, and everything seems to work! > > If that's really the only problem, I wouldn't consider this a bug. > IIRC, the 'unpacked' form of gfxboot archives is a special case of > SYSLINUX anyway, grub expects/needs the files in their packed form. > Then this change just needs to be documented somewhereIf it's true that the unpacked archive was always a Syslinux only feature than I'm happy to mark that feature as deprecated, especially given that there's such a simple upgrade path (move everything into the archive). If anyone is absolutely relying on the old behaviour and has a concrete reason we need to continue to support it, shout out. -- Matt Fleming, Intel Open Source Technology Center
On Thu, Jul 04, 2013 at 12:52:20PM +0100, Matt Fleming wrote:> On Thu, 04 Jul, at 08:45:33AM, Andreas Heinlein wrote: > > Looks like you're right. I added '*.tr *.hlp *.pcx back.jpg > > gfxboot.cfg langlist' to the 'bootlogo' archive, and now I get the > > menu, and everything seems to work! > > > > If that's really the only problem, I wouldn't consider this a bug. > > IIRC, the 'unpacked' form of gfxboot archives is a special case of > > SYSLINUX anyway, grub expects/needs the files in their packed form. > > Then this change just needs to be documented somewhere > > If it's true that the unpacked archive was always a Syslinux only > feature than I'm happy to mark that feature as deprecated, especially > given that there's such a simple upgrade path (move everything into the > archive). > > If anyone is absolutely relying on the old behaviour and has a concrete > reason we need to continue to support it, shout out.Sorry for not noticing this thread for such a long time. We only ran across this rather recently when we switched to syslinux 6 and found that our boot menu broke ... This is really pretty problematic for us. Yes, it's possible for us to work around this change by adding some more files to the packed archive, and I'll probably do that in the short term. However, some of these files are required outside the archive as well (gfxboot.cfg at least), and so that means we'll end up duplicating things; and the image files routinely have to be changed by people customising Ubuntu images, which is a pretty common use case for us. I anticipate this being a non-trivial source of confusion for people building images based on ours. I'm sure it isn't trivial to reintroduce the COMBOOT API. Is there any other sensible way that this feature might be reintroduced? (Incidentally, the statement about GRUB above makes little sense to me, unless maybe it's talking about GRUB 1. GRUB 2 is perfectly happy to read files directly off an ISO9660 filesystem or basically whatever else it comes across.) Thanks, -- Colin Watson [cjwatson at ubuntu.com]
Colin Watson wrote:> On Thu, Jul 04, 2013 at 12:52:20PM +0100, Matt Fleming wrote: > > On Thu, 04 Jul, at 08:45:33AM, Andreas Heinlein wrote: > > > Looks like you're right. I added '*.tr *.hlp *.pcx back.jpg > > > gfxboot.cfg langlist' to the 'bootlogo' archive, and now I get the > > > menu, and everything seems to work! > > > > > > If that's really the only problem, I wouldn't consider this a bug. > > > IIRC, the 'unpacked' form of gfxboot archives is a special case of > > > SYSLINUX anyway, grub expects/needs the files in their packed form. > > > Then this change just needs to be documented somewhere > > > > If it's true that the unpacked archive was always a Syslinux only > > feature than I'm happy to mark that feature as deprecated, especially > > given that there's such a simple upgrade path (move everything into the > > archive). > > > > If anyone is absolutely relying on the old behaviour and has a concrete > > reason we need to continue to support it, shout out. > > Sorry for not noticing this thread for such a long time. We only ran > across this rather recently when we switched to syslinux 6 and found > that our boot menu broke ... > > This is really pretty problematic for us. Yes, it's possible for us to > work around this change by adding some more files to the packed archive, > and I'll probably do that in the short term. However, some of these > files are required outside the archive as well (gfxboot.cfg at least), > and so that means we'll end up duplicating things; and the image files > routinely have to be changed by people customising Ubuntu images, which > is a pretty common use case for us. I anticipate this being a > non-trivial source of confusion for people building images based on > ours.Can you please explain which files are required outside the archive? gfxboot should pull all files (including gfxboot.cfg) from the archive.> I'm sure it isn't trivial to reintroduce the COMBOOT API. Is there any > other sensible way that this feature might be reintroduced? > > (Incidentally, the statement about GRUB above makes little sense to me, > unless maybe it's talking about GRUB 1. GRUB 2 is perfectly happy to > read files directly off an ISO9660 filesystem or basically whatever else > it comes across.) > > Thanks,AFAIK gfxboot does not support GRUB 2; it works with Syslinux, LILO and GRUB 1. Sebastian
On 06/20/2014 07:31 AM, Colin Watson wrote:> > Sorry for not noticing this thread for such a long time. We only ran > across this rather recently when we switched to syslinux 6 and found > that our boot menu broke ... > > This is really pretty problematic for us. Yes, it's possible for us to > work around this change by adding some more files to the packed archive, > and I'll probably do that in the short term. However, some of these > files are required outside the archive as well (gfxboot.cfg at least), > and so that means we'll end up duplicating things; and the image files > routinely have to be changed by people customising Ubuntu images, which > is a pretty common use case for us. I anticipate this being a > non-trivial source of confusion for people building images based on > ours. > > I'm sure it isn't trivial to reintroduce the COMBOOT API. Is there any > other sensible way that this feature might be reintroduced? > > (Incidentally, the statement about GRUB above makes little sense to me, > unless maybe it's talking about GRUB 1. GRUB 2 is perfectly happy to > read files directly off an ISO9660 filesystem or basically whatever else > it comes across.) >The COMBOOT API has lived its run, it simply cannot be sanely brought back to life. It wouldn't work with something like EFI no matter how much work we did. This ultimately comes back to a request of mine since at least 10 years to get (all of) gfxboot rewritten in C so it can be made to operate against a more general framebuffer framework. I don't have a good solution for this. It is a sizable project to rewrite the gfxboot byte code interpreter in C, I suspect, but at least it ought to be *doable* ... which is the good part of gfxboot being a byte code interpreter at all. It really is just a resource issue. -hpa