booting another system from running linux (kexec)

booting another system from running linux (kexec)

[Gerd v. Egidy]

Hi,

I want to create a central disk image management for lots of clients. Theses 
clients should be able to boot into different OS. The OS is cached on the 
local disk but should be updated via rsync at boot time.

One solution would be:

1. boot a linux kernel (via PXE)
2. execute some programs (update the disk images via rsync)
3. show a boot menu (execute a grub program to show the regular grub boot 
menu, with or without splashscreen)
4. boot into the selected system (maybe via the new kexec system call)

The system to boot into should not be limited, e.g. different linux distros, 
*bsd, dos, windows,...

I think currently steps 3 and 4 are not implemented. Are there plans for 
making something like this possible?

Another way to solve this would be to add scripting, dhcp, rsync and writing 
to linux-fs/ntfs directly into grub. But I think that is a huge task and not 
flexible enough.

Or do you guys have better ideas?

Kind regards,

Gerd

Re: booting another system from running linux (kexec)

[Tomas Ebenlendr]

> Another way to solve this would be to add scripting, dhcp, rsync and writing 
> to linux-fs/ntfs directly into grub. But I think that is a huge task and not 
> flexible enough.
> 

That is what is grub2 supposed, It will have modules. Anyone can write
his own modules, and have grub2 installed from his distro. (If we will
not believe that, we will probably not choose to implement grub2, at
least in this way....). But grub2 is not stable (nor beta) yet. I don't
know if current state can be considered as alpha (probably yes).

Ad flexibility: you can always boot any system to do the hard work, and
then reboot the system from script. Grub then needs only to know that
hard work should be done. (This means no fs-write support, and you can
choose between compatibility with rsync, and other way of updating. If
your updates are stored centrally, you can use 'timestamps'. If
timestamp on your os is older than timpestamp obtained from server, the
hard work should be done.)
Scripting and dhcp are both issues that we want in grub2. Sounds this
reasonable to you?

-- 
                                 Tomas 'ebi' Ebenlendr
                                 http://get.to/ebik
                                 PF 2004.72919708814

Re: booting another system from running linux (kexec)

[Johan Rydberg]

Tomas Ebenlendr <ebik@artax.karlin.mff.cuni.cz> wrote:

: Scripting and dhcp are both issues that we want in grub2. [...]

Have there been any discussion on how the scripting language will look
like?  Will it be a simple language, specific to GRUB2, or will it
some other language be re-used.

I would love to see a powerful scripting language, something like
Scheme.  But I'm not sure how usefull it would be.  Scheme is a very
simple, but yet powerful language that can very well be used for
scripting.  I'm not sure, though, that it fits into the context of
GRUB2.

~j

Re: booting another system from running linux (kexec)

[Marco Gerards]

Johan Rydberg <jrydberg@night.trouble.net> writes:

> Tomas Ebenlendr <ebik@artax.karlin.mff.cuni.cz> wrote:
>
> : Scripting and dhcp are both issues that we want in grub2. [...]
>
> Have there been any discussion on how the scripting language will look
> like?  Will it be a simple language, specific to GRUB2, or will it
> some other language be re-used.

No, there was not much discussion about this.

> I would love to see a powerful scripting language, something like
> Scheme.  But I'm not sure how usefull it would be.  Scheme is a very
> simple, but yet powerful language that can very well be used for
> scripting.  I'm not sure, though, that it fits into the context of
> GRUB2.

IMHO something bash-like would be the best.  Everyone knows these kind
of languages.  And the config file will look a lot like the one of
GRUB Legacy.

That is the problem of scheme, most people don't know it.  For me it
is important that someone who wants a simple scripting feature don't
have to learn a completely new language.  I assume most uses of GRUB
are not programmers.

Thanks,
Marco

Re: booting another system from running linux (kexec)

[Gerd v. Egidy]

On Thursday 23 September 2004 21:30, Tomas Ebenlendr wrote:
> > Another way to solve this would be to add scripting, dhcp, rsync and
> > writing to linux-fs/ntfs directly into grub. But I think that is a huge
> > task and not flexible enough.
>
> That is what is grub2 supposed, It will have modules. Anyone can write
> his own modules, and have grub2 installed from his distro. (If we will
> not believe that, we will probably not choose to implement grub2, at
> least in this way....). But grub2 is not stable (nor beta) yet. I don't
> know if current state can be considered as alpha (probably yes).

Ok, but I'll have to re-implement everything as grub module. Except if busybox 
would be included into grub by default...

> Ad flexibility: you can always boot any system to do the hard work, and
> then reboot the system from script. Grub then needs only to know that
> hard work should be done. (This means no fs-write support, and you can
> choose between compatibility with rsync, and other way of updating. If
> your updates are stored centrally, you can use 'timestamps'. If
> timestamp on your os is older than timpestamp obtained from server, the
> hard work should be done.)
> Scripting and dhcp are both issues that we want in grub2. Sounds this
> reasonable to you?

Requiring two boots everytime is not acceptable. But requiring a second boot 
after a remote update is ok.

So the scheme would be:

1. boot into grub
2. grub script is running
	- network if detection
	- driver loading
	- dhcp
	- read timestamps from server (e.g. http)
	- compare timestamps with what is stored on local partition
3. if timestamps match: show regular grub boot menu
3. if timestamps differ:
	- boot into special small linux
	- update partitions via rsync
	- set new timestamps
	- reboot

I'm just wondering if it is not a very ambitious goal to develop nic drivers 
for all cards supported under linux. And I think that is duplicating a lot of 
work. 

So wouldn't it be better concept to boot a _very stripped down_ version of 
linux, let the scripting and stuff be done by the already existing busybox 
framework and use kexec to do the real boot into the final os? This would 
turn big parts of grub into regular linux userspace code.

I know that this is a very different approach than what you are currently 
doing. I do not want to offend anyone with my ideas or put the work you guys 
are doing in question. Maybe I'm missing some important part that prevents my 
scheme from being practical.

Kind regards,

Gerd

 

Re: booting another system from running linux (kexec)

[Marco Gerards]

"Gerd v. Egidy" <lists@egidy.de> writes:

> On Thursday 23 September 2004 21:30, Tomas Ebenlendr wrote:
>> > Another way to solve this would be to add scripting, dhcp, rsync and
>> > writing to linux-fs/ntfs directly into grub. But I think that is a huge
>> > task and not flexible enough.
>>
>> That is what is grub2 supposed, It will have modules. Anyone can write
>> his own modules, and have grub2 installed from his distro. (If we will
>> not believe that, we will probably not choose to implement grub2, at
>> least in this way....). But grub2 is not stable (nor beta) yet. I don't
>> know if current state can be considered as alpha (probably yes).
>
> Ok, but I'll have to re-implement everything as grub module. Except if busybox 
> would be included into grub by default...

GRUB is not an operating system... :)

> I'm just wondering if it is not a very ambitious goal to develop nic drivers 
> for all cards supported under linux. And I think that is duplicating a lot of 
> work. 

GRUB Legacy has network drivers already.

> So wouldn't it be better concept to boot a _very stripped down_ version of 
> linux, let the scripting and stuff be done by the already existing busybox 
> framework and use kexec to do the real boot into the final os? This would 
> turn big parts of grub into regular linux userspace code.

Can kexec boot GNU/Hurd, *BSD or function as a chainloader?  Booting
into linux takes a lot of time and this is not practical because you
will have to boot something anyway.

--
Marco