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