Re: [Xen-users] booting domU with multiple concatenated ramdisks?

[Ferenc Wagner <wferi@xxxxxxx>]

Mark Williamson <mark.williamson@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users