Re: update-grub & Xen boot stanza generation

I actually had the kernel arg=val repeated twice originally, but the xen-devel guys said to use dummy=dummy. I thought the repeated kernel was less likely to break things. -Bruce On Thu, May 20, 2010 at 4:59 PM, Seth Goldberg wrote: > > But isn't the argument after "multiboot" the multiboot k

Re: update-grub & Xen boot stanza generation

Bruce Edge wrote: > 2010/5/20 Vladimir 'φ-coder/phcoder' Serbinenko > > > Bruce Edge wrote: > > Hi > > Apologies in advance if this is already in the works. > > > > I wanted to provide an etc/grub.d rule for generating boot > stanzas for > > Xe

Revised Amendment

Hi, I've revised the UEFI System Table portion of my previous amendment proposal to include flags that specify a 32- or 64-bit UEFI system (it's essential to know this if the OS is 64-bit and will be doing EFI Runtime calls). Vladimir suggested that instead of flags in this tag, another tag

Re: update-grub & Xen boot stanza generation

But isn't the argument after "multiboot" the multiboot kernel file? Wouldn't GRUB try to load the file called "dummy=dummy"? --S Quoting Bruce Edge, who wrote the following on Thu, 20 May 2010: There's a bug in certain hypervisor versions where it drops the first parameter. This is the a

Re: update-grub & Xen boot stanza generation

2010/5/20 Vladimir 'φ-coder/phcoder' Serbinenko > Bruce Edge wrote: > > Hi > > Apologies in advance if this is already in the works. > > > > I wanted to provide an etc/grub.d rule for generating boot stanzas for > > Xen based systems such that it would end up in the upstream grub release. > > If

Re: update-grub & Xen boot stanza generation

There's a bug in certain hypervisor versions where it drops the first parameter. This is the accepted workaround, pass a dummy param as the first entry. -Bruce On Thu, May 20, 2010 at 4:45 PM, Seth Goldberg wrote: > > What is this 'dummy=dummy' on the multiboot line? > > --S > > > Quoting Bru

Re: update-grub & Xen boot stanza generation

Bruce Edge wrote: > Hi > Apologies in advance if this is already in the works. > > I wanted to provide an etc/grub.d rule for generating boot stanzas for > Xen based systems such that it would end up in the upstream grub release. > If this conforms to the appropriate conventions, could someone > po

Re: update-grub & Xen boot stanza generation

What is this 'dummy=dummy' on the multiboot line? --S Quoting Bruce Edge, who wrote the following on Thu, 20 May 2010: Hi Apologies in advance if this is already in the works. I wanted to provide an etc/grub.d rule for generating boot stanzas for Xen based systems such that it would end up

update-grub & Xen boot stanza generation

Hi Apologies in advance if this is already in the works. I wanted to provide an etc/grub.d rule for generating boot stanzas for Xen based systems such that it would end up in the upstream grub release. If this conforms to the appropriate conventions, could someone possibly add it ? It's basically

Re: Converting Ubuntu CDs to GRUB

On 20 May 2010 20:43, Colin Watson wrote: > On Thu, May 20, 2010 at 11:13:02AM -0700, Colin D Bennett wrote: >> On Thu, 20 May 2010 18:35:54 +0100 >> Colin Watson wrote: >> > I've written up a brief description of our needs here: >> > >> >   https://wiki.ubuntu.com/FoundationsTeam/Specs/MaverickC

Re: Converting Ubuntu CDs to GRUB

On Thu, May 20, 2010 at 11:13:02AM -0700, Colin D Bennett wrote: > On Thu, 20 May 2010 18:35:54 +0100 > Colin Watson wrote: > > I've written up a brief description of our needs here: > > > > https://wiki.ubuntu.com/FoundationsTeam/Specs/MaverickCDBoot > > > > I think that the extensions we'd n

Re: Converting Ubuntu CDs to GRUB

On Thu, 20 May 2010 18:35:54 +0100 Colin Watson wrote: > I would like to convert Ubuntu CDs to boot using GRUB for Ubuntu > 10.10. > > This is a bit ambitious. We're currently using ISOLINUX with SuSE's > gfxboot extensions, and extensive theming to offer various custom > menus. A number of the

Converting Ubuntu CDs to GRUB

I would like to convert Ubuntu CDs to boot using GRUB for Ubuntu 10.10. This is a bit ambitious. We're currently using ISOLINUX with SuSE's gfxboot extensions, and extensive theming to offer various custom menus. A number of the facilities we depend on there aren't yet present in gfxmenu, and whi

Re: Are BSD partitions not supported?

On Wed, May 19, 2010 at 9:41 PM, C. P. Ghost wrote: > The next test would be to create two slices on an image, > and redo the tests on the second slice (which won't start > at offset 0 of the disk, so we can be sure the logic is > correct). Will do this tomorrow with the patched grub, > and report

Re: GCC 4.5

Vladimir 'φ-coder/phcoder' Serbinenko wrote: Hello, all. I've noticed that GCC 4.5 is released and is available in debian. With this version -mregparam=3 bug is fixed. So I intend to remove all NESTED_FUNC_ATTR and use -mregparm=3 only on gcc >=4.5 and -mregparam=1 otherwise. This has the disadva

GCC 4.5

Hello, all. I've noticed that GCC 4.5 is released and is available in debian. With this version -mregparam=3 bug is fixed. So I intend to remove all NESTED_FUNC_ATTR and use -mregparm=3 only on gcc >=4.5 and -mregparam=1 otherwise. This has the disadvatantage of increasing binary size with pre-4.5

grub2 not compiling - grub_gettext error

Compiling grub2 for x86_64-UEFI ./configure --with-platform=efi --target=x86_64 --program-transform-name=s,grub,grub2, --enable-efiemu --enable-mm-debug --enable-grub-fstest --enable-grub-mkfont --disable-nls --prefix=/grub2_efi_x64 and i386-BIOS ./configure --with-platform=pc --enable-efiemu --

Re: Migrations to xorriso

Hi, > I'm thinking to allow passing arbitrary options to xorriso by just > putting it on command line. > Do you recommend to switching to native xorriso interface? There are differences how file names without "=" are handled. xorriso maps /my/dir to /my/dir. xorriso -as mkisofs maps /my/dir to /d

Re: Migrations to xorriso

Hi, attached is an updated patch to summarize my current proposal for grub-mkrescue. My reply to mails of Vladimir and Seth seems still stuck in eggs.gnu.org. (At least that was the culprit last time.) The current proposal follows Vladimir's idea: > I'm thinking to allow passing arbitrary optio