Xen users - Apr 2008 - booting domU with multiple concatenated ramdisks?

Hi!

Some bootloaders (eg. syslinux) have to ability to load multiple
ramdisks, effectively concatenating them.  This makes it very easy
to augment ramdisks, like eg. customizing an installer.  Can I do
something similar with XEN?  Separating the ramdisk cpio arhives with
commas in the config file didn''t work...
-- 
Thanks,
Feri.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> Some bootloaders (eg. syslinux) have to ability to load multiple
> ramdisks, effectively concatenating them.  This makes it very easy
> to augment ramdisks, like eg. customizing an installer.  Can I do
> something similar with XEN?  Separating the ramdisk cpio arhives with
> commas in the config file didn''t work...
I don''t think this is currently possible.  There was some work done by
a
developer in adding the ability to load multiple modules with the domain 
builder (for supporting GNU HURD) but I don''t know what happened to it.
I
don''t *think* it was actually checked in.

What do you actually require here?  Do you *literally* just need concatenation 
of the ramdisks in memory?  Some metadata too?  It''s probably not very
hard
to hack pygrub to build a compound "ramdisk" image containing the 
concatenated contents of multiple files (possibly with some other goop in 
there) in a file, then pass *that* to the domain builder.  It would be harder 
to modify the domain builder itself to load multiple files directly.

Cheers,
Mark

-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Mark Williamson <mark.williamson@cl.cam.ac.uk> writes:
>> Some bootloaders (eg. syslinux) have to ability to load multiple
>> ramdisks, effectively concatenating them.  This makes it very easy
>> to augment ramdisks, like eg. customizing an installer.  Can I do
>> something similar with XEN?  Separating the ramdisk cpio arhives with
>> commas in the config file didn''t work...
>
> I don''t think this is currently possible.  There was some work
done by a
> developer in adding the ability to load multiple modules with the domain 
> builder (for supporting GNU HURD) but I don''t know what happened
to it.  I
> don''t *think* it was actually checked in.
>
> What do you actually require here?  Do you *literally* just need
concatenation
> of the ramdisks in memory?
Yes, pretty much.  Basically, I''d like to have an easy means of
dropping random files into the ramdisk.
> Some metadata too?
I don''t understand this, but probably no.
> It''s probably not very hard to hack pygrub to build a compound
> "ramdisk" image containing the concatenated contents of multiple
> files (possibly with some other goop in there) in a file, then pass
> *that* to the domain builder.  It would be harder to modify the
> domain builder itself to load multiple files directly.
It''s mostly trivial either way, right now I worked around by
decompressing both cpio archives, concatenating the compressing the
result again.  That effectively merges their contents behind the back
of the boot loader (or domain builder).  It''s just somewhat
inconvenient when one has to test lots of different modifications one
after the other.
-- 
Regards,
Feri.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> >> Some bootloaders (eg. syslinux) have to ability to load multiple
> >> ramdisks, effectively concatenating them.  This makes it very easy
> >> to augment ramdisks, like eg. customizing an installer.  Can I do
> >> something similar with XEN?  Separating the ramdisk cpio arhives
with
> >> commas in the config file didn''t work...
> >
> > I don''t think this is currently possible.  There was some
work done by a
> > developer in adding the ability to load multiple modules with the
domain
> > builder (for supporting GNU HURD) but I don''t know what
happened to it.
> > I don''t *think* it was actually checked in.
> >
> > What do you actually require here?  Do you *literally* just need
> > concatenation of the ramdisks in memory?
>
> Yes, pretty much.  Basically, I''d like to have an easy means of
> dropping random files into the ramdisk.
Ahhhhh, that''s different to what I thought you meant, I''m
afraid.

I thought you meant you had an unusual OS that just wanted multiple ramdisk 
filesystems in sequence, in memory ...
> > Some metadata too?
>
> I don''t understand this, but probably no.
... in which case you might have wanted some metadata to describe where the 
multiple ramdisk images were.

I see now that what you''re really after is a means of modifying a
single base
ramdisk with other files at boot time - am I right now?
> It''s mostly trivial either way, right now I worked around by
> decompressing both cpio archives, concatenating the compressing the
> result again.  That effectively merges their contents behind the back
> of the boot loader (or domain builder).  It''s just somewhat
> inconvenient when one has to test lots of different modifications one
> after the other.
It sounds inconvenient!

Well there''s not a way of doing this with pygrub at the moment (as far
as I
know).  I can see how it''d be a good feature to be able to
"overlay" files
onto a base ramdisk image at boot time.

It seems like something that you could probably write a short shell script 
for, to automate the process of building the new ramdisk and starting a 
domain with it?

I think you can do stuff like:

xm create <config_file> ramdisk=/path/to/ramdisk

instead of putting the ramdisk path directly into the config file.  This 
should make it easy for your script to build a new ramdisk and start the 
domain using it as an initrd.

Do you think this would do?  Otherwise, maybe you could tell us more about 
what problem you''re actually trying to solve in case somebody can
suggest an
easier way of doing it?

Cheers,
Mark

-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Mark Williamson <mark.williamson@cl.cam.ac.uk> writes:
>>>> Some bootloaders (eg. syslinux) have to ability to load
multiple
>>>> ramdisks, effectively concatenating them.  This makes it very
easy
>>>> to augment ramdisks, like eg. customizing an installer.  Can I
do
>>>> something similar with XEN?  Separating the ramdisk cpio
arhives with
>>>> commas in the config file didn''t work...
>>>
>>> I don''t think this is currently possible.  There was some
work done by a
>>> developer in adding the ability to load multiple modules with the
domain
>>> builder (for supporting GNU HURD) but I don''t know what
happened to it.
>>> I don''t *think* it was actually checked in.
>>>
>>> What do you actually require here?  Do you *literally* just need
>>> concatenation of the ramdisks in memory?
>>
>> Yes, pretty much.  Basically, I''d like to have an easy means
of
>> dropping random files into the ramdisk.
>
> Ahhhhh, that''s different to what I thought you meant, I''m
afraid.
>
> I thought you meant you had an unusual OS that just wanted multiple ramdisk
> filesystems in sequence, in memory ...
No, I''m really after the easy thing.
>>> Some metadata too?
>>
>> I don''t understand this, but probably no.
>
> ... in which case you might have wanted some metadata to describe where the
> multiple ramdisk images were.
Got it.  Fortunately, it''s not the case.
> I see now that what you''re really after is a means of modifying a
single base
> ramdisk with other files at boot time - am I right now?
Exactly.
>> It''s mostly trivial either way, right now I worked around by
>> decompressing both cpio archives, concatenating the compressing the
>> result again.  That effectively merges their contents behind the back
>> of the boot loader (or domain builder).  It''s just somewhat
>> inconvenient when one has to test lots of different modifications one
>> after the other.
>
> It sounds inconvenient!
>
> Well there''s not a way of doing this with pygrub at the moment (as
far as I
> know).  I can see how it''d be a good feature to be able to
"overlay" files
> onto a base ramdisk image at boot time.
>
> It seems like something that you could probably write a short shell script 
> for, to automate the process of building the new ramdisk and starting a 
> domain with it?
Sure, that''s exactly what I did.
> I think you can do stuff like:
>
> xm create <config_file> ramdisk=/path/to/ramdisk
>
> instead of putting the ramdisk path directly into the config file.  This 
> should make it easy for your script to build a new ramdisk and start the 
> domain using it as an initrd.
>
> Do you think this would do?  Otherwise, maybe you could tell us more about 
> what problem you''re actually trying to solve in case somebody can
suggest an
> easier way of doing it?
That would again be a very convenient (and also more versatile) way of
achieving this.  Currently, I modified the config file to use another
ramdisk, which I create each time by concatenating the original with
another cpio archive containing the modifications.  The only wart is
that this way the whole thing must be compressed together, I can''t
simply concatenate the compressed cpio arhives, but have to decompress
the originals first, then concatenate, then compress the result.  If
it was handled by the domain builder, that could decompress each
ramdisk one after the other right into their final place in memory...
Well, if it''s done by the domain builder at all, and not by the kernel.
-- 
Thanks,
Feri.

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users