PVM guests and p[yv]grub and the extra= parameter

PATCH New Dan Magenheimer 3 participants 9 messages Jul 2, 2008 – Jul 16, 2008

Share & tools

Dan Magenheimer

author

2008-07-02 17:17 UTC #0 lore raw

At Xen Summit, Ian's presentation touched on PVGrub which is intended to be a more secure replacement for PyGrub.

I've noticed that PyGrub doesn't honor the extra= parameter in a VM config file (which adds additional kernel command line parameters, e.g. extra=1 will boot single-user mode).

Will PVGrub?

Thanks,
Dan

===================================
Thanks... for the memory
I really could use more / My throughput's on the floor The balloon is flat / My swap disk's fat / I've OOM's in store Overcommitted so much
(with apologies to the late great Bob Hope)

_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2008-07-02 17:22 UTC #1 lore raw

Since pvgrub is basically grub in a minios wrapper, the config parsing aspects should work identically to normal grub.

-- Keir

Quoted 22 lines · Dan Magenheimer

At Xen Summit, Ian's presentation touched on PVGrub which is intended to be a more secure replacement for PyGrub.
I've noticed that PyGrub doesn't honor the extra= parameter in a VM config file (which adds additional kernel command line parameters, e.g. extra=1 will boot single-user mode).
Will PVGrub?
Thanks,
Dan
===================================
Thanks... for the memory
I really could use more / My throughput's on the floor The balloon is flat / My swap disk's fat / I've OOM's in store Overcommitted so much
(with apologies to the late great Bob Hope)
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Samuel Thibault

2008-07-02 17:29 UTC #2 lore raw

In reply to Dan Magenheimer

Quoted 8 lines · Dan Magenheimer, le Wed 02 Jul 2008 11:17:45 -0600, a écrit :

At Xen Summit, Ian's presentation touched on PVGrub which is intended to be a more secure replacement for PyGrub.
I've noticed that PyGrub doesn't honor the extra= parameter in a VM config file (which adds additional kernel command line parameters, e.g. extra=1 will boot single-user mode).
Will PVGrub?

Mmm, actually in PVGrub extra is used to point to the menu.lst file that should be loaded. It could however append the remainder of extra to the kernel command line. That however doesn't look very appealing to me, on the principles. Instead, would for instance being able to set the menu entry to be activated by default be ok?

Samuel

Dan Magenheimer

author

2008-07-02 17:42 UTC #3 lore raw

Quoted 2 lines

That however doesn't look very appealing to me, on the principles.

I agree that would be a bit of a hack.

Quoted 2 lines

Instead, would for instance being able to set the menu entry to be activated by default be ok?

That would be nice too, but doesn't replace the niceness of being able to alter the booting behavior of a pv guest without ever mucking with grub interactive edits or grub configuration files.

Thanks,
Dan

Quoted 31 lines

-----Original Message-----
From: Samuel Thibault [mailto:[email protected]]
Sent: Wednesday, July 02, 2008 11:30 AM
To: Dan Magenheimer
Cc: Xen-Devel (E-mail)
Subject: Re: [Xen-devel] PVM guests and p[yv]grub and the extra= parameter
Quoted 8 lines · Dan Magenheimer, le Wed 02 Jul 2008 11:17:45 -0600, a écrit :
At Xen Summit, Ian's presentation touched on PVGrub which is intended to be a more secure replacement for PyGrub.
I've noticed that PyGrub doesn't honor the extra= parameter in a VM config file (which adds additional kernel command line parameters, e.g. extra=1 will boot single-user mode).
Will PVGrub?
Mmm, actually in PVGrub extra is used to point to the menu.lst file that
should be loaded. It could however append the remainder of extra to the
kernel command line. That however doesn't look very appealing to me, on
the principles. Instead, would for instance being able to set the menu
entry to be activated by default be ok?
Samuel

Samuel Thibault

2008-07-16 01:28 UTC #4 lore raw

Hello,

Quoted 5 lines · Dan Magenheimer, le Wed 02 Jul 2008 11:42:43 -0600, a écrit :

Quoted 2 lines
That however doesn't look very appealing to me, on the principles.
I agree that would be a bit of a hack.

Quoted 7 lines

Quoted 2 lines
Instead, would for instance being able to set the menu entry to be activated by default be ok?
That would be nice too, but doesn't replace the niceness of being able to alter the booting behavior of a pv guest without ever mucking with grub interactive edits or grub configuration files.

Another possibility would be to provide the menu.lst as a ramdisk. We keep the confinment of grub inside the domain, but still provide full configurability.

Samuel

Dan Magenheimer

author

2008-07-16 04:18 UTC #5 lore raw

Quoted 11 lines

Quoted 7 lines
Quoted 2 lines
Instead, would for instance being able to set the menu entry to be activated by default be ok?
That would be nice too, but doesn't replace the niceness of being able to alter the booting behavior of a pv guest without ever mucking with grub interactive edits or grub configuration files.
Another possibility would be to provide the menu.lst as a ramdisk. We keep the confinment of grub inside the domain, but still provide full configurability.

That's a neat solution. Still not as clean as an extra= vm.cfg parameter though. (Think about instructing a novice user over the phone how to construct a grub.conf file from scratch!) But it's much better than the other alternatives.

Dan

Samuel Thibault

2008-07-16 11:24 UTC #6 lore raw

PATCH 1/1 PVM guests and p[yv]grub and the extra= parameter

PV-GRUB: allow passing menu.lst as a ramdisk

Signed-off-by Samuel Thibault <[email protected]>

stubdom/grub/mini-os.c +3 -1

diff -r 530efcde6203 stubdom/grub/mini-os.c
@@ -681,7 +681,9 @@
         config_file[sizeof(config_file) - 1] = 0;
         if (!strncmp(config_file, "(nd)", 4))
             preset_menu = "dhcp";
-    } else
+    } else if (start_info.mod_len)
+        preset_menu = (void*) start_info.mod_start;
+    else
         preset_menu = "dhcp --with-configfile";
 
     mbi.drives_addr = BOOTSEC_LOCATION + (60 * 1024);

Dan Magenheimer

author

2008-07-16 12:35 UTC #7 lore raw

In reply to Dan Magenheimer

Quoted 10 lines

Quoted 1 line
Another possibility would be to provide the menu.lst as a
ramdisk. We
Quoted 1 line
keep the confinment of grub inside the domain, but still
provide full
Quoted 1 line
configurability.
That's a neat solution. Still not as clean as an extra= vm.cfg parameter though. (Think about instructing a novice user over the phone how to construct a grub.conf file from scratch!) But it's much better than the other alternatives.

Thinking about this a bit more, were you thinking about thh vm config file providing a file name on the dom0 filesystem? Or providing the entire menu.lst file in the vm config file. Or either?

It would be neat if you could put in the vm config file something like (as a contrived example):

bootconfig="
default=0
timeout=10
title Linux 2.6.25

	kernel /vmlinuz-2.6.25 ro root=xxx
      initrd /initrd-2.6.25.img
title Linux 2.6.25
	kernel /vmlinuz-2.6.25 ro root=xxx debug
      initrd /initrd-2.6.25.img

Then you could just tell a customer to change default=0 to default=1, or change debug to, for example, clock=pit, or whatever.

Thanks,
Dan

Samuel Thibault

2008-07-16 12:52 UTC #8 lore raw

Quoted 11 lines · Dan Magenheimer, le Wed 16 Jul 2008 06:35:47 -0600, a écrit :

Quoted 10 lines
Quoted 1 line
Another possibility would be to provide the menu.lst as a
ramdisk. We
Quoted 1 line
keep the confinment of grub inside the domain, but still
provide full
Quoted 1 line
configurability.
That's a neat solution. Still not as clean as an extra= vm.cfg parameter though. (Think about instructing a novice user over the phone how to construct a grub.conf file from scratch!) But it's much better than the other alternatives.

Quoted 4 lines

Thinking about this a bit more, were you thinking about thh vm config file providing a file name on the dom0 filesystem? Or providing the entire menu.lst file in the vm config file. Or either?

The latter.

Quoted 12 lines

It would be neat if you could put in the vm config file something like (as a contrived example):
bootconfig="
default=0
timeout=10
title Linux 2.6.25
	kernel /vmlinuz-2.6.25 ro root=xxx
      initrd /initrd-2.6.25.img
title Linux 2.6.25
	kernel /vmlinuz-2.6.25 ro root=xxx debug
      initrd /initrd-2.6.25.img

Quoted 5 lines

"
Then you could just tell a customer to change default=0 to default=1, or change debug to, for example, clock=pit, or whatever.

You can obtain that by putting that into a dom0 file and referencing it from the ramdisk option (the name becomes a bit unfortunate...)

Samuel